═══ 1. Table of Contents ═══ The DCF/2 Online Help covers the following topics. Click on the highlighted topic to get help. o Introduction o "The Big Picture" o Installation o DCF/2 and System Startup o OS/2 File Systems o User Reference o VDU Maintenance o Troubleshooting o Glossary of Terms o Appendix ═══ 2. Introduction ═══ The DCF/2 is an "on-the-fly" disk compression facility which allows you to increase the effective data storage capacity of your OS/2 computer system. The DCF/2 is unlike the traditional "on-the-fly" data compression products available to DOS users. Unlike DOS compression products, which require you to pre-allocate the total size of the compressed drive -- the compressed drives you create using the DCF/2 grow dynamically. For example, when you create a 100MB compressed drive and format it, it occupies less than 350K of physical space. You can create your first "VDU" even if you are down to your last few megabytes of physical space. Unlike DOS compression products, the DCF/2 does not automatically compress the contents of the "host" drive. Instead, you decide what you want to move to compressed storage. As you move your data onto your "VDU", you recover physical space on its "host" drive. Unlike DOS compression products, DCF/2 compressed drives are formatted using OS/2's High Performance File System. With the DCF/2, you can experience the speed and efficiency of this powerful file system without reformatting or repartitioning your existing physical hard drive. Unlike DOS compression products, DCF/2 compressed drives can reside on any device supported under OS/2 -- network and removeable media (read-write opticals, magneto opticals and floppies, etc.) included! Unlike DOS compression products, the DCF/2 is a full 32-bit utility -- designed to grow with your OS/2 desktop. ═══ 2.1. The DCF/2 and OS/2 Version Support ═══ The DCF/2 does not support versions of OS/2 prior to OS/2 2.0. If you are not sure which version of OS/2 is on your system, you can query OS/2. Go to an OS/2 window or full screen and type: SYSLEVEL If you are running a version of OS/2 prior to OS/2 2.11 (OS/2 2.1 plus the Service Pak), only non-HPFS based physical media can serve as "host" drives for your VDUs. To place DCF/2 VDUs on your HPFS-formatted partitions, your base operating system must be OS/2 2.11. To order the Service Pak, call IBM at (800) 494-3044. DCF/2 Virtual Disk Units are always formatted as HPFS volumes. If you do not currently have the High Performance File System installed on your system, the DCF/2 installation program will install the correct version for you, based upon the version of OS/2 running on your system. o OS/2 2.11 and HPFS Installed o OS/2 2.11 No HPFS.IFS Installed o OS/2 2.0 or 2.1 No HPFS Installed o OS/2 2.0 or 2.1 and HPFS Installed ═══ 2.1.1. OS/2 2.11 and HPFS Installed ═══ If you are running OS/2 2.11 and the High Performance File System is installed, but the version is older than the one shipped on the DCF/2 distribution diskette, the DCF/2 installation program will make a backup copy of your existing file and then replace it with the HPFS.IFS dated April 19, 1994. ═══ 2.1.2. OS/2 2.11 No HPFS.IFS Installed ═══ If you are running OS/2 2.11 and the High Performance File System is not currently installed on your system, the DCF/2 install program will install the OS/2 2.11 UHPFS.DLL and the HPFS.IFS dated the April 19, 1994, to the correct directory and will add the HPFS statement to your CONFIG.SYS. (If your existing HPFS file is later than April 19, 1994, it is left unchanged.) ═══ 2.1.3. OS/2 2.0 or 2.1 No HPFS Installed ═══ If you are running version 2.X of OS/2 but prior to 2.11 and do not have the High Performance File System installed, the DCF/2 installation program will install the OS/2 2.1 GA UHPFS.DLL and HPFS.IFS and insert the HPFS statement in your CONFIG.SYS file. ═══ 2.1.4. OS/2 2.0 or 2.1 and HPFS Installed ═══ Finally, if you are running version 2.X of OS/2 but prior to 2.11, have the High Performance File System installed and have partitions formatted as HPFS, the HPFS will be left unchanged. IN THIS CASE, DO NOT CREATE DCF/2 VIRTUAL DISK UNITS ON YOUR HPFS FORMATTED PARTITIONS -- USE ONLY FAT-BASED HOSTS. The remainder of this introduction will present a few of the basic terms that you will encounter frequently throughout this document. ═══ 2.2. Basic Terms ═══ Installing the DCF/2 is easy. Before you do so, however, you need to have a basic understanding of the terms we use to describe the differences between the three types of storage units -- physical, logical and virtual. (Sound scary? It's not.) Physical Disk Unit Your hard disk or hard drive is a Physical Disk Unit (PDU). You can reach out and touch it. You use low level utilities like FORMAT and CHKDSK on it. It may have one or more "logical" partitions. Logical Disk Unit A network drive is a Logical Disk Unit (LDU). You cannot reach out and touch it. You cannot perform physical operations on it. You cannot run low level utilities like FORMAT and CHKDSK on it. Virtual Disk Unit A DCF/2 Virtual Disk Unit (VDU) looks like a real, physical disk unit to OS/2. It has real geometry (so many heads, so many sectors per track). You run low level utilities like FORMAT and CHKDSK on it. It does not exist in the physical sense. It "exists" as a "storage container" for your compressed data on either a physical or a logical disk unit. ═══ 3. The DCF/2 Big Picture ═══ The DCF/2 is an on-the-fly data compression facility for all OS/2 file systems. Transparent to all standard DOS, Windows, and OS/2 applications software, the DCF/2 works with all existing disk structures -- NO repartitioning of your existing system is needed. The DCF/2 is a full 32-bit program for OS/2 2.X. The DCF/2 supports all OS/2 file systems as host storage for compressed, HPFS-formatted virtual disk units (VDUs), so long as you are running OS/2 2.11 or greater. For users running OS/2 2.0, OS/2 2.1 or or OS/2 for Windows, only FAT-based host storage is supported. For the OS/2 2.11 user, the host drive can be an existing FAT or HPFS partition, a network drive -- even removable media like floppies or read/write or magneto optical drives. The DCF/2 is a system of building blocks designed to grow with your entire operating environment -- IBM's OS/2 2.1 32-bit multitasking makes it all possible! The following topics are covered in this section: o Product Architecture o How It Works o What is a "VDU"? o Compression ═══ 3.1. Product Architecture ═══ The following diagram of the DCF/2's architecture details these building blocks: The DCF/2 Architecture The DCF/2 is designed with each element externalized. Third-party developers can add compression, encryption, and other disk related capabilities to your system environment (contact the PSC technology lab for pricing and details of the DCF/2 CDE API kit). ═══ 3.2. How It Works ═══ When the OS/2 operating system or an application program requests disk accesses, the DCF/2 Physical Device Driver (PDD) receives the request and repackages it for processing by the Ancillary Control Process (ACP). The ACP is a standard, high-level software layer which shuffles the compressed disk request between Compression/Decompression Engines (CDE's), Input/Output Engines (IOE's), and physical disk structures. The ACP compressed disk requests are processed and managed by standard OS/2 disk and file services. The DCF/2 can use all logical media, such as hard disk drives, LAN network drives, and removable media like floppies. This architecture guarantees compatibility with all OS/2 system and application software updates. The DCF/2 VDU Control Process initializes all VDUs during OS/2 system startup and then launches the DCF/2 space manager. The latter monitors the amounts of virtual and physical space in use to prevent the user from running out of physical space on the host volume. The DCF/2 benefits from all OS/2 file and memory management features, so that applications "see" the DCF/2 VDU as a "real" disk. The DCF/2 takes advantage of the OS/2 High Performance File System, allowing DCF/2 VDU's to utilize all of its advanced features like 254 character file names, integrated extended attributes, and support for HUGE disks. ═══ 3.3. What is a "VDU"? ═══ "VDU" is short for "Virtual Disk Unit." If you think in terms of the types of drives you work with, they are usually either "physical" or "logical." A physical drive is one you can reach out and touch. You use low level utilities, like FORMAT and CHKDSK, on a physical drive. A network drive is an example of a logical disk unit. You cannot touch it. And you cannot run low level utilities, like FORMAT and CHKDSK, on it. A "Virtual Disk Unit" is a cross between the two. Like a network drive, it is logical rather than physical. Like a physical drive, you use low level utilities, like FORMAT and CHKDSK, on it. In reality, a VDU is a flat, simple file with no EAs (extended attributes), in which your data is stored in compressed format. Because it is just a flat file, it can reside on any device supported by OS/2 -- be that FAT, HPFS, network or removable media. ═══ 3.4. Compression ═══ There are two basic kinds of data compression: (1) Lossless and (2) Lossy. Lossless data compression requires that whatever goes into the compression engine comes out in the same form. Lossy compression allows for statistical recovery of information, allowing data dilution. The DCF/2 supports only lossless data compression technologies. Uncompressed sectors are passed through the DCF/2's character based compression engine. The resulting logical disk sectors (LDS) require less physical space than their uncompressed counterparts. Each virtual disk unit has an intelligent disk allocation table (DAT) which describes where compressed logical disk sectors reside within the container file. In addition, the DAT keeps track of the compression type performed on each compressed chunk and how many times the chunk has been accessed, compressed, and/or decompressed. Your VDU develops a personality of its own as it matures, based upon the way you use it. o What to Compress o Compressing Compressed Files o What Not to Compress o Compressing OS/2 Itself ═══ 3.4.1. What to Compress ═══ The DCF/2 includes a utility called the "Disk Compression Analysis Tool" or "DCAT." It allows you to look at the data on your system in terms of the amount of space storing the data on a virtual disk unit will return to you. You can use the DCAT to look at your whole physical disk unit or at directories and subdirectories on your logical drives. You can sample data in a variety of ways depending upon your needs. In general, you will find that user files compress best. For example, Lotus AmiPro user files compress at about 5:1. Windows and DOS program files compress next best -- usually at 2:1 and better. Game files compress poorly at 1.5:1. For detailed information about specific programs and file types, please refer to the Appendix in your copy of the Disk Compression Facility for OS/2 Introduction ═══ 3.4.2. Compressing Compressed Files ═══ Some files won't compress or will compress very little. These include files you have archived with utilities like ZIP(tm), PKZIP(tm), ARC(tm), and LHARC(tm), and files that are shipped already compressed -- for example, game and sound files. While they do not compress particulary well, you can still move these to a VDU. ═══ 3.4.3. What Not to Compress ═══ Some files should not be compressed at all. For example, all files needed to boot your system must be left uncompressed, because they are required before your compressed virtual disk units are available. For more information on compressing OS/2, refer to the following section on (Compressing OS/2 Itself.) You should leave uncompressed files you want access to if you use Dual Boot or Boot Manager to boot an operating system other than OS/2. Data stored on your DCF/2 virtual disk units is not accessible when you boot native DOS. ═══ 3.4.4. Compressing OS/2 Itself ═══ The operating system (OS/2) is like a puzzle which rebuilds itself each time you "reboot" your system. It does so in phases. The first is system initialization. The second is system startup. During system initialization, base device drivers, device drivers, and basic system-wide information are loaded. The DCF/2 physical device driver (DCF2PDD.SYS) loads at this time. During system startup the operating system loads high-level file services, user interface and management programs (Presentation Manager), and initializes user-specific actions (STARTUP.CMD and STARTUP FOLDER). The DCF/2 ancillary control process (DCF2ACP.EXE) and its associated support processes load at this time. Those parts of OS/2 required prior to the time when OS/2 loads the DCF/2 device drivers and executes the CALL statement to startup the DCF/2 cannot be stored on a compressed drive. Our recommendation is that you allocate to OS/2 the space it requires and compress your applications software, utilities, user files and things like icons, clipart and communications threads, etc. That said, you can move some parts of OS/2 to a VDU and run them quite successfully. For example, you can move WINOS2 to a VDU to free up about 8MB of space on your OS/2 boot drive. When you do so, you must modify the OS/2 PATH and DPath statements to properly reference the new WINOS2 subdirectory. Also modify the AUTOEXEC.BAT file to point to the new WIN\OS2 directory. If you installed them, you can also gain additional space on your OS/2 boot drive by moving EPD (the Enhanced Editor) and OS/2 reference files (.INF) to a VDU. ═══ 4. Installation ═══ The installation process includes creating VDUs, copying the DCF/2 program files to a target directory, updating your CONFIG.SYS file and restarting your system. Note: The DCF/2 Version 1.2 installation program should only be used to install the DCF/2 programs and create your first VDUs. It is not intended to be used to create additional VDUs or to update VDUs created under previous versions of the DCF/2. If you currently have VDUs installed that were created using Version 1.1a of the DCF/2, please refer to the appendix for converting these VDUs to Version 1.2. Note: Attention network clients: If you use a LAN and the LAN drives letters you use are adjacent to your first physical drive letter, they will have to be moved to after the VDU drive letters. Drive letter swapping is not available in this release, but will be included in a future version of the software. If you have network drives defined, please logoff of the network prior to running the DCF/2 install program. The section on installation covers the following topics: o Choosing the Target Drive o Selecting the Number of VDUs o Creating VDUs o Updating the Configuration o DCF/2 Icons & README o Restarting Your System o Formatting VDUs with AutoFormat o AutoChecking VDUs o Formatted, Clean and Ready for Data o DCF/2 Icon o Installing from a Network Server o Updating Workstation from a Server o Registration The DCF/2 installation program can be run from the DCF/2 distribution diskette in either your A: or B: drive. Network workstations will copy the DCF/2 distribution files from a directory on their server to a temporary directory on the workstation and run the installation program from the temporary directory. If the DCF/2 distribution files have been downloaded from an online service to a temporary directory, the install program will be run from that directory. Note: Do not name the temporary directory DCF2. Doing so will cause the installation to fail. To run the DCF/2 Installation program, change to the source drive (or temporary directory) and type: INSTALL. ═══ 4.1. Choosing the Target Drive ═══ The "DCF/2 Installation" screen asks you to select the "Target Drive" for the DCF/2 program files. This is the uncompressed drive from which OS/2 will run the DCF/2 programs. ═══ 4.2. Selecting the Number of VDUs ═══ On the "DCF/2 Installation" screen you will enter the "Total VDUs" to be created by the install program. This number can be changed at a later time. The DCF/2 allows you to create as many or as few VDUs as suit your needs. No two systems are alike. Some users have a single C: drive. Other users have two physical drives divided into multiple logical partitions. Still others have network drives, CD-ROMs and Read/Write or Magneto Optical devices installed. The DCF/2 allows you to choose whether to create a VDU for each logical partition or device, or to create several small VDUs on a single partition. In choosing the number of VDUs to create, you need to look at the partition(s) and devices you have on your computer and the kind of data you store on them. The data on a system usually falls into one of three categories and occupies more or less a fixed percentage of the physical space: Data Categorized by Frequency of Use ┌─────────────────────────┬────────────────────┬─────────────────────────┐ │Category │As % of Physical │Examples │ │ │Space │ │ ├─────────────────────────┼────────────────────┼─────────────────────────┤ │Write seldom/Read seldom │60 % │Icons, .pic files, │ │ │ │communications threads, │ │ │ │tutorials, online │ │ │ │archives, database │ │ │ │backups, etc. │ ├─────────────────────────┼────────────────────┼─────────────────────────┤ │Write seldom/Read often │25% │Applications │ ├─────────────────────────┼────────────────────┼─────────────────────────┤ │Write often/Read often │15% │Live data │ └─────────────────────────┴────────────────────┴─────────────────────────┘ Typically, applications and games compress at 1.5 - 1.75:1, user files compress at 1.75 - 2.25:1 and icons and communications threads compress at 2.25 - 5.0:1. Note: The DCF/2 is shipped with a complete disk compression analysis tool (DCAT). This easy-to-use utility allows you to measure precisely how your files, directories and sub-directories will compress before you move anything. We encourage you to make extensive use to this powerful tool. If you are using a laptop with a docking station, you may want to create an additional "dummy" VDU for each of the devices present when docked but missing when running portable. (Refer to the section on "Tips & Techniques.") For a number of reasons, we recommend that you create several smaller VDUs rather than a few large ones. We base this recommendation on the length of time required to run CHKDSK /F on a large VDU versus a smaller one; as well as the amount of time required to optimize a large VDU versus a smaller one. Finally multiple smaller VDUs offer greater backup flexibility. ═══ 4.3. Creating VDUs ═══ The first VDU you create will take the first physical drive letter available on your system; the second will take next available drive letter, and so on up to the total number of VDUs you requested be created. For each VDU, you select the drive letter for the "Host Physical Unit for VDU" and the "Total Size in MB." Note: The DCF/2 will allocate its VDU drive letters contiguously from the first available physical drive letter on your computer system at the time the DCF/2 physical device driver loads. This means that, for example, laptop users with docking stations will probably need to use one CONFIG.SYS when docked and a second CONFIG.SYS when running portable. Or, they will use a single CONFIG.SYS and create an additional "dummy" VDU to serve as a placeholder for each of the devices (like CD-ROMs) that are not there when running in portable mode. (Refer to the section in the Appendix on laptops.) o Choosing Where to Put VDUs o Selecting the Host Physical Unit o Selecting VDU Size o Cancelling Selections ═══ 4.3.1. Choosing Where to Put VDUs ═══ This version of the DCF/2 allows you to create as many virtual disk units as you have drive letters available. You can "put" your VDU's on any of your existing disk units, on network drives, floppies, tape, Read-Write Opticals -- any writeable device supported by OS/2 so long as you are running OS/2 2.11 or greater. ═══ 4.3.2. Selecting the Host Physical Unit ═══ The "Host Physical Unit" is the physical location on which the Virtual Disk Unit resides. Note: If the Host Physical Unit contains the SWAPPER.DAT file, we recommend that you preallocate space for the swap file by adjusting the settings in your CONFIG.SYS. ═══ 4.3.3. Selecting VDU Size ═══ The default size is 128 MegaBytes. This is not based upon an in-depth analysis of the size of the host physical unit. It is only there to prevent you from creating a VDU of no size at all. A VDU containing a fairly even distribution of user, program and miscellaneous files (e.g., icons, threads, clipart, etc.) will typically compress at 2:1. If you opt to take the default size of 128MB, the VDU when full will occupy about 64MB of physical space on the host drive. As a rule of thumb, calculate the total virtual space you'll have available as follows: Take the total size of your physical drive, subtract from that the space required by OS/2, the SWAPPER.DAT file and the amount you would like to reserve for uncompressed storage. This remainder multiplied by the expected compression ratio (ECR) equals the estimated total virtual space. (Physical space - (OS/2 including SWAPPER.DAT + reserved space))xECR= Estimated Virtual Space If you plan to store primarily program files and .DLLs -- which typically compress at about 1.85 - 2:1 -- multiply the remainder by 2 to determine the size VDU to create. If you plan to store primarily user files, icons, etc. -- which typically compress at 2.25 -5:1 -- multiply the remainder by 3 to determine the size of VDU to create. You can create a single VDU of a size equal to the estimated total virtual space. Or, you can create several smaller VDUs with a combined size equal to the estimated total virtual space. We strongly recommend that you create multiple, smaller VDUs rather than a few larger ones. Having several smaller VDUs affords you greater control over what you compress where and also affords you greater flexibility in creating and maintaining backups of your data. You enter the size in MegaBytes rather than in bytes. The "Total Size" is the total capacity OS/2 will believe the DCF/2 Virtual Disk Unit to have. You will want this size to be close to the amount of storage you should get. ═══ 4.3.4. Cancelling Selections ═══ Once you have indicated your choices, you can choose to "Create or Update VDU," get "Help," or "Exit/Cancel." The latter allows you to change your mind or correct an unwanted choice. Following the successful creation of your first VDU, the process repeats itself automatically for each subsequent VDU up to the total number of VDUs you requested. ═══ 4.4. Updating the Configuration File ═══ Once your VDUs have been created, the DCF/2 program files are copied to the "Target Drive" and the install program adds the DEVICE, SET and CALL statements to your configuration file. Automatic Update The install program creates the CONFIG.DCF file. This file will replace your existing CONFIG.SYS. First, however, your existing CONFIG.SYS is saved as CONFIG.!D!. The install program includes an edit option to allow you to edit the load order of devices in your CONFIG.SYS before completing the installation process and restarting your system. In most cases, you will not need to do so. Whenever the DCF/2 makes a change to your CONFIG.SYS file, that change will always be delimited by lines and REM statements which explain what was changed and the date and time stamp of the change. o Example of Changes to the CONFIG.SYS File ═══ 4.4.1. Example of Changes to the CONFIG.SYS File ═══ The order of the statements in the CONFIG.SYS file has been adjusted to put the HPFS.IFS statement at the top, followed by the DISKCACHE statement if there are FAT-formatted drives. This is followed by the original CONFIG.SYS statements, (with the earlier HPFS and DISKCACHE statements REM'd out with a time stamp), followed by the DCF/2 virtual disk definitions, followed by DCF/2 call statement: where x: is the target drive to which you installed the DCF/2 programs. CALL=x:\DCF2\DCF2.EXE /A:STARTUP The HPFS and (optionally) DISKCACHE statement(s) may have been modified to optimize the cache allocation and/or to add AUTOCHECK switches. The DCF/2 requires that the HPFS.IFS have a minimum cache of 1024. In the following example, the /CACHE parameter determines the number of KiloBytes of memory allocated to HPFS cache blocks. The /AUTOCHECK tells the HPFS to CHKDSK any 'dirty' HPFS disks: IFS=C:\OS2\HPFS.IFS /CRECL:64 /CACHE:1536 /AUTOCHECK:FEG "Dirty" disks result from improperly shutting down OS/2. This can be the result of voluntary action on the user's part -- turning off the computer with out running shut down. Or, this can result from an involuntary action -- a system TRAP or system hang, or a power failure. The DISKCACHE statement is required only if there are FAT drives on the system. If there are no FAT formatted drives, this statement is REM'd out thereby freeing up the memory it would have otherwise committed. In the following DISKCACHE statement, the first number is the number of KiloBytes allocated to FAT caching. The LW parameter enables FAT lazy-writing, the number following that is the threshold, and the AC: specifies which FAT drives to CHKDSK during system startup. For additional information on the DISKCACHE statement, refer to the OS/2 Online Help. DISKCACHE=1024,LW,32,AC:C The following commands can improve the system's caching performance, depending upon how the system is used: REM >> RUN=x:\OS2\CACHE.EXE /MAXAGE:40000 REM >> RUN=x:\OS2\CACHE.EXE /DISKIDLE:30000 REM >> RUN=x:\OS2\CACHE.EXE /BUFFERIDLE:20000 Due to the multithreaded nature of the OS/2 system startup, the user may need to place the above RUN commands in the STARTUP.CMD folder instead of in the CONFIG.SYS. The contents of the CONFIG.SYS file follow these statements and these are followed by the DCF/2 device, set and call statements at the end of the CONFIG.SYS. The DCF/2 statements will be commented and surrounded with delimiting lines. The DCF/2 device drivers are order dependent and each must appear on a separate line. The DCF2PDD.SYS comes first. The /U:n defines n number of DCF/2 virtual disk units to be created. DEVICE=C:\DCF2\DCF2PDD.SYS /u:3 DEVICE=C:\DCF2\DCF2CDE.SYS The DCF_VDU_x environment variable points to DCF/2 VDU x: SET DCF2_VDU_E=C:\DCF2\DCF2_E.VDU SET DCF2_VDU_F=C:\DCF2\DCF2_F.VDU SET DCF2_VDU_G=C:\DCF2\DCF2_G.VDU The following DCF/2 diagnostic statements are to aid in diagnosing virtual drive characteristics and problems: REM >> SET DCF2_ACP_LOGNG=3 REM >> SET DCF2_VCP_LOGNG=3 REM >> SET DCF2_ACP_DEBUG=3 REM >> SET DCF2_VCP_DEBUG=3 The "CALL=" statement starts the DCF/2. If you have put DCF/2 virtual disk units on network disks or other media which is not available at boot time, move this statement to the STARTUP.CMD or to the command procedure that starts your network. The following call statement tells OS/2 to startup the DCF/2: CALL=C:\DCF2\DCF2.EXE /A:STARTUP The REM'd statements and delimiting lines may be deleted if you prefer. Do, however, exercise caution so as not to delete more than the comments. ═══ 4.5. DCF2 Icons and README.12 ═══ DCAT and Online Help Icons During the final part of the installation process, the program will place the DCAT and DCF/2 Online Help icons on your desktop and display the DCF/2 README file. It will then ask if you would like to restart your system at this time. README.12 The README.12 file shipped on the DCF/2 disk contains the latest release notes for this version of the software. You can elect to have both the README.1st and README.12 copied to the DCF/2 program directory when you run the DCF/2 install program. Regardless, you will have an opportunity to view the file automatically just prior to exiting the DCF/2 install program and restarting your system. ═══ 4.6. Restarting Your System ═══ The DCF/2 device statements added to your CONFIG.SYS will not take effect until such time as your system is restarted. Before exiting the DCF/2 install program, the program will ask you if you would like to have your system restarted automatically at this time. If you answer, "yes," the install program will run shutdown. You can choose to exit the program and do the reboot later. Once you have successfully created your VDUs and your system has been rebooted, each of your VDUs will automatically be formatted using the HPFS format. On a standard OS/2 system, this will happen prior to the time OS/2 loads the Workplace Shell. ═══ 4.7. Formatting VDUs with AutoFormat ═══ The VDUs you created during the install are unformatted until your system restarts; then the DCF/2 uses the OS/2 format command to format each of them as HPFS drives, automatically. The format uses an undocumented OS/2 2.1 feature -- the NOF switch -- for fast format. In most cases, the NOF format works fine. If, for some reason, it does not seem to work on your system, answer "no" at the format prompt. Format will then run on the VDU without the switch. The formatting process can take from a few seconds using the switch to a couple of minutes without it, depending upon the size of the drive being formatted and the speed of your computer. The format command will prompt you to enter a volume label or press enter. At this point, the volume information is written to the VDU's boot record. ═══ 4.8. AutoChecking VDUs ═══ The DCF/2 uses OS/2's CHKDSK /F to check the newly formatted drive. Be sure to "press any key to continue" when prompted to do so! This process repeats for each of the VDUs you created during the installation program. ═══ 4.9. Formatted, Clean and Ready for Data ═══ The DCF/2 startup continues, the DCF/2 Space Manager is launched for each VDU and the Workplace Shell comes up. At this point, your VDUs are formatted, empty and available. You may now begin to move data and user files onto them -- using the tools you normally use to move directories and files on your system. ═══ 4.10. Shut Down ═══ As of Version 1.2, the DCF/2 shut down is completely integrated with OS/2's standard "right mouse button" shut down. If you have a DCF/2 System Shutdown icon on your desktop, you should delete it. ═══ 4.11. Installing from a Network Server ═══ You can install the DCF/2 to a central location on a server. First, make a directory on the server, e.g., DCF2DIST; then copy the DCF/2 program files to that directory. COPY A:*.* P:\DCF2DIST\*.* In the above example, the DCF/2 disk is in your A: drive and you are copying the files to a directory called DCF2DIST on server drive P: On each workstation, create a temporary directory; then logon to the appropriate network drive and change to the DCF2DIST directory. Copy the files from the DCF/2 program directory on the server to the temporary directory on the workstation. (In, the following example, the temporary drive "TMP" is on drive "x".) COPY P:\DCF2DIST\*.* x:\TMP Important Note: Do not use "DCF2" as the temporary directory name. Important: Before installing the DCF/2, the workstation must logoff of the network. If this is not done, the first VDU will take an incorrect drive letter. The client workstation then installs the DCF/2 from the temporary directory, by changing to the temporary directory and running the DCF/2 install program. X:\TMP\INSTALL ═══ 4.12. Updating Workstations from a Network Server ═══ When the install program is used to update an existing DCF/2 program area on a client workstation, only the DCF/2 program files are changed. This process can be done directly from the central server and does not require that the client workstation logoff the network at any time during the procedure. ═══ 4.13. Registration ═══ Your DCF/2 package includes a registration card. Please take the time to fill out your registration card and return it to us so that we can notify you when updates to the DCF/2 are available. If you are interested in testing future releases of the DCF/2, please check the "Beta" test program box. All registered users who would like to beta test are eligible to do so. Access to CompuServe or IBMLink is a required. ═══ 5. DCF/2 and Your System Startup ═══ At OS/2 system startup (on a standard system running the Presentation Manager), the DCF/2 startup process will complete before the Presentation Manager comes up. The DCF/2 startup process involves scanning all of the VDUs, formatting and/or running CHKDSK on any VDUs that are either unformatted or were left "dirty" by an improper shut down, and launching the space manager. Normally, during startup, the DCF/2 audio and screen messages are enabled. The default setting for the count-down (the interval during which the keyboard is enabled to receive a user-entered SHIFT or CONTROL key) is 10 seconds. These can be disabled by adding the appropriate optional parameter to the CALL= statement which starts the DCF/2 from your CONFIG.SYS. Refer to the Command Reference in the Appendix for a list of optional parameters. You can use CONTROL-C to terminate the AUTOCHECK process. However, as a safeguard, the VDU remains "dirty" until you run CHKDSK /F on it -- even if you run a proper shut down in between. If you find you want to interrupt the startup process, you can. When prompted, depress the CONTROL key to launch an OS/2 command processor. To resume the startup process, type: EXIT. Far less often, you may find you need to keep the DCF/2 from loading at all. If you feel the DCF/2 is somehow interfering with your boot process, you can prevent even the DCF/2 device drivers from loading. Depress one or both SHIFT key(s) shortly after the OS/2 "Loading, please wait" startup message under the big OS/2 logo. OS/2 will not load the DCF/2 device drivers. Note: Your VDUs will not be available until you restart your system or until you manually start the DCF/2 processes with the command: X:\DCF2\DCF2.EXE /A:STARTUP If your system is improperly shut down -- you turn it off without running the OS/2 shut down, you have a power failure, or your system experiences a trap or the system hangs necessitating a reboot -- the DCF/2 will automatically run CHKDSK /F on each VDU during the boot process. This checks your VDUs for errors and makes the necessary repairs. It keeps you from causing further damage to a damaged VDU. The remainder of this section covers startup on your system of the: o The DCF/2 Device Drivers o The DCF/2 Control Program o The DCF/2 VDU Control Process o The DCF/2 Ancillary Control Process ═══ 5.1. The DCF/2 Device Drivers ═══ The DCF/2 is not designed as an IFS (installable file system). The DCF/2 install program placed two device drivers in your CONFIG.SYS file. OS/2 loads these at system startup. The DCF2PDD The DCF/2 Physical Device driver defines a block device in your CONFIG.SYS that "creates" your compressed drive. It must load in your CONFIG.SYS prior the DCF2CDE.SYS. The DCF2CDE The DCF/2 Compression Decompression Engine (DCF2CDE.SYS) is a character-based device driver. As requested data is passed to it, it compresses or decompresses that data. ═══ 5.2. The DCF/2 Control Program ═══ OS/2 runs the DCF/2 Control Program each time your system starts up. It is also the command line interface for both PM and non-PM systems. You will use it if you want to create or remove VDUs once you have installed the DCF/2 and created your initial VDUs. The CALL statement the DCF/2 install program inserted at the end of your CONFIG.SYS, calls the DCF/2 control program, which in turn lauches the DCF2VCP and DCF2ACP programs. Refer to the appendix for a list of DCF2.EXE commands and parameters. ═══ 5.3. The DCF/2 VDU Control Process ═══ The DCF/2 VDU Control Process (DCF2VCP) performs two functions. First, it creates the control processes run during your system's startup. It initializes the disks. Then, during run-time, it controls space management for each VDU using the DCF2INFO.CMD file. Space Manager File Each VDU has a DCF/2 Space Manager File, DCF2INFO.CMD. This file reports the VDU's current compression ratio and available compression ratio after recompaction. This file also reports the total size of, amount of space in use by and space available for both the VDU's physical host drive and for the VDU itself. The purpose of this file is to protect you from running out of physical space on the VDU's host drive -- a condition which can jeopardize the integrity of the VDU. The file may appear to be very large at times. In reality, it occupies very little space and is stored in the VDU's Disk Allocation Table in single-byte entries. To display the file, go to an OS/2 command prompt and type the VDU drive letter followed by a colon and DCF2INFO, e.g., X:DCF2INFO. If you are not in the root, use \X:DCF2INFO, where X is the drive letter for the VDU. To exit, type Control-C. ═══ 5.4. The DCF/2 Ancillary Control Process ═══ The DCF/2 Ancillary Control Process (DCF2ACP) is the software controller for the virtual disk drive. It connects drive letter X to the VDU container file. For example, you might have a VDU drive letter E: and a VDU container file C:\DCF2\DCF2_E.VDU. The DCF2ACP "connects" the two. While you will need to do so only infrequently -- for example, to delete a VDU container file or to update the DCF/2 program files -- you can easily stop and start the DCF2ACP using the DCF/2 Control Program. To try it, change to your DCF2 program directory, type DCF2 /A:SHUTDOWN to stop the DCF2ACP and DCF2 /A:STARTUP to restart it. Note: If the DCF2ACP is stopped, your VDUs and the programs and data on them are not available. This makes sense if you think in terms of your physical disk controller -- were you pull your physical disk controller out of your computer, the programs and files on your physical disk would not be available! ═══ 6. OS/2 File Systems ═══ A file system determines how data is stored on your disk. OS/2 supports two basic file systems: FAT and HPFS. The key difference between the two file systems is the way in which they manage the date stored on your disk. The following topics are covered in this section: o The FAT File System o The HPFS File System o HPFS vs. FAT Summary o DCF/2 and the OS/2 File Systems o Floppies o Physical Drive Management o Virtual Drive Management o Backing Up Data ═══ 6.1. The FAT File System ═══ The FAT file system stores data using clusters. The size of the cluster used depends upon the size of the drive. Typically, the cluster size is 4 Kbytes; but as the size of the drive increases, the size of the cluster increases to 8 or even 16Kbytes. This increase is due to the limitation on the maximum number of entries that can be supported by the File Allocation Table (64K entries). The FAT supports only the "eight-dot-three" convention for file names. That is, file names can use up to eight alphanumeric characters followed by a period and an extension of three alphanumeric characters, e.g., MYFILE.DOC, TESTFILE.WK1. ═══ 6.2. The HPFS File System ═══ The High Performance File System or HPFS stores data at sector granularity -- 512 bytes per sector. The HPFS includes sophisticated caching and lazy writing mechanisms. Finally, the HPFS employs an extremely efficient mechanism for searching file directories. It supports file names up to 254 characters in length, providing the user with the ability to use far more descriptive file names than the eight character plus three character extension available using FAT. ═══ 6.3. HPFS vs. FAT Summary ═══ Statistically over a FAT formatted drive, one half of the cluster size is lost in slack space. Actually, it can be worse than that -- especially if you have a lot of small files, like icons. An icon is typically slightly less than 1Kbytes big, but a FAT-formatted partition, with a minimum cluster size of 4Kbytes will require 4Kbytes to store this 1Kbyte file. If you store 4,000 1K big icon files on a FAT partition, you will use 16MB -- 12MB of the 16MB are lost in slack space! To store the same 1K icon file on an HPFS-formatted drive requires only 1024 bytes. To store the same 4,000 1Kbyte big icon files that required 16MB on a FAT-formatted partition, requires only 4MB on an HPFS-formatted volume! You recover 12MB of physical space simply by storing the files on an HPFS rather than a FAT formatted volume. The HPFS also offers several other benefits. Among these are a highly efficient binary-tree search mechanism, ability to use up to 254 characters for file names, and optional cache tuning parameters which can improve system performance by 25 to 30%. ═══ 6.4. DCF/2 and the OS/2 File Systems ═══ DCF/2 VDUs are formatted using the OS/2 High Performance File System (HPFS). Based upon extensive comparisons of the two file systems, we have concluded that an HPFS-formatted drive is faster and more efficient than the equivalent size FAT (File Allocation Table) formatted drive -- independent of the size of the drive. ═══ 6.5. Floppies ═══ A floppy drive is DASD device. It is always formatted to use the File Allocation Table. Using the DCF/2, you can put HPFS-formatted VDU's on FAT-based floppy devices. ═══ 6.6. Physical Drive Management ═══ It is important to take 'good care' of your physical disk storage before doing anything with DCF/2 virtual disk units. This is because the virtual disk units reside on physical storage and if the physical storage is damaged or corrupted in some way, that can cause unnecessary risk to the virtual disk container file. In most cases, the only thing you have to do to maintain your physical disk integrity, it to make sure you 'AUTOCHECK' your physical disk drives at startup time. The DCF/2 installation procedure automatically insures this by correcting the IFS= and DISKCACHE= CONFIG.SYS statements, if the AUTOCHECK option is not already there. If you do experience a physical disk integrity problem make sure you shut down properly and then make sure that the CHKDSK operation is performed during system restart. ═══ 6.7. Virtual Drive Management ═══ DCF/2 virtual disk units should be treated exactly as you do physical disk units, (except that, as noted above) the physical disk management MUST be performed BEFORE any DCF/2 virtual disk maintenance. ═══ 6.8. Backing Up Data ═══ The DCF/2 virtual disk units offer you a great deal of backup flexibility. You can back up the VDU's host drive, and, in so doing, create an image back up of the VDU container file. Or, you can back up the individual files on the VDU, file-by-file. In either case, the important point is that you do back up your data (both physical and virtual). Disk drives are mechanical things -- eventually they are going to fail; so don't put this important system management function off until it's too late! o Image Back Up o File-by-File Back Up ═══ 6.8.1. Image Back Up ═══ You can back up the VDU container file itself and have an 'image' backup of the compressed volume. Before you do an 'image' backup, you must stop the DCF2ACP. Otherwise, the VDU container file is locked open. (If you get an error doing a back up of the VDU's host drive, this is the most likely cause.) To stop the DCF2ACP, use the following command: DCF2 /A:SHUTDOWN After you complete an image back up, restart the DCF2ACP using the following command: DCF2 /A:STARTUP ═══ 6.8.2. File by File Back Up ═══ You can back up the individual files in the VDU and have file-by-file backup of your compressed data. This method provides an uncompressed copy of each file in the VDU's compressed storage. Unlike the image back up, during a file-by-file back up, the DCF2ACP remains running. ═══ 7. User Reference ═══ The User Reference is divided into the following sections, which describe the functions and operations of the DCF/2 program modules, as well as how to move files from physical to virtual space. o System Startup o Control Program o Ancillary Control Process o VDU Control Process o LED Monitors o Shutdown Program o Optimize Utility o DCAT (Disk Compression Analysis Tool) o Moving Files from Physical to Virtual Space ═══ 7.1. System Startup ═══ During system startup, the DCF/2 is linked to the OS/2 operating system to provide transparent access to your virtual, compressed disk storage. The HPFS.IFS The DCF/2 relies on the OS/2 High Performance File System (HPFS) for all virtual disk operations. Normally the IFS= CONFIG.SYS statement will be at the beginning of your system startup. The DCF/2 Device Statements The DCF/2 virtual disk "block devices" are created when OS/2 loads the DCF2PDD.SYS device driver. The "/u:" option determines how many template virtual disk units are created. These are associated with virtual disk unit container files using environment strings (see below). The DCF/2 Environment Strings The DCF/2 associates a virtual drive unit with it's container file using a process environment string of the form: DCF2_VDU_x=full_file_path where "x" is the VDU drive letter to be associated with "full_file_path" file name. A full file path is normally "d:\dir\filename.ext." The CALL=DCF2.EXE Normally, the DCF/2 is started at the very end of the system CONFIG.SYS using the CALL= startup statement. During DCF/2 startup, the system startup can be interrupted or aborted (as described in the section on System Startup). Using Startup.CMD instead of CALL=DCF2.EXE If you have placed DCF/2 VDUs on network drives which are not available during system startup, move the "CALL=DCF2 /A:STARTUP" statement from the CONFIG.SYS to your STARTUP.CMD file. Place it in the STARTUP.CMD after the statements that start your network software. ═══ 7.2. Control Program (DCF2.EXE) ═══ OS/2 uses the DCF/2 Control program every time your system starts up. It is the program called by the CALL statement, that the DCF/2 installation program added to the end of your CONFIG.SYS. The DCF/2 Control program starts the DCF/2 VDU Control Process and the DCF/2 Ancillary Control Process, which initialize and check your VDUs at system startup. You can also use the DCF/2 Control program from the command line from an OS/2 window or full screen. Using the DCF/2 Control program, you can: o Refresh the Space Manager file for VDU x o Start the DCF/2 control processes o Stop the DCF/2 control processes o Create additional VDUs To use the program, you must first change to the DCF2 program directory. Then type the DCF2 command followed by at least one parameter. The command syntax is as follows: DCF2 /[parameter 1] /[parameter 2] /[parameter 3] Most DCF2 commands use only one parameter. The exception is the command to create a new VDU. In this case, you specify /v:create /s: /f:, where /s: is the size of the VDU in megabytes, and /f: is the file specification of the VDU you want to create. The following table lists the optional parameters available for the DCF2.EXE program: DCF2 Control Program Command Line Parameters ┌────────┬──────────────────────┬────────────────────────────────────────┐ │Command │Parameter │Function │ ├────────┼──────────────────────┼────────────────────────────────────────┤ │DCF2 │/A:STARTUP │Starts the DCF/2 Control Processes. │ │ │ │Makes your VDUs available. │ ├────────┼──────────────────────┼────────────────────────────────────────┤ │DCF2 │/+ │"Shorthand" method to start the DCF/2 │ │ │ │Control Processes. │ ├────────┼──────────────────────┼────────────────────────────────────────┤ │DCF2 │/A:STARTUP/q │Starts the DCF/2 Control Processes │ │ │ │without beeps signaling "keyboard │ │ │ │enabled." │ ├────────┼──────────────────────┼────────────────────────────────────────┤ │DCF2 │/A:STARTUP/Q │Starts the DCF/2 Control Processes │ │ │ │without beeps signaling "keyboard │ │ │ │enabled" and without writing the DCF/2 │ │ │ │startup messages to the screen. │ ├────────┼──────────────────────┼────────────────────────────────────────┤ │DCF2 │/A:STARTUP/T:n │Starts the DCF/2 Control Processes with │ │ │ │a count-down of n seconds. This is the │ │ │ │interval during which the keyboard is │ │ │ │enabled to accept a user entered SHIFT │ │ │ │or CONTROL key to to interrupt the │ │ │ │DCF/2's load process. │ ├────────┼──────────────────────┼────────────────────────────────────────┤ │DCF2 │/A:Startup /D │Starts the DCF/2 Control Processes and │ │ │ │says to delete the DCF2INFO.CMD at │ │ │ │startup. Use this option if you run │ │ │ │virus scanning software. It will │ │ │ │eliminate uncecessary scanning time. │ ├────────┼──────────────────────┼────────────────────────────────────────┤ │DCF2 │/A:STATUS │Reports the Status of the DCF/2 Control │ │ │ │Processes (currently running or │ │ │ │currently not running). │ ├────────┼──────────────────────┼────────────────────────────────────────┤ │DCF2 │/A:SHUTDOWN │Stops the DCF2 Control Processes. Your │ │ │ │VDUs are unavailable when you stop the │ │ │ │DCF/2. Use this command before you │ │ │ │OPTIMIZE a VDU or if you need to delete │ │ │ │a VDU. │ ├────────┼──────────────────────┼────────────────────────────────────────┤ │DCF2 │/- │"Shorthand" method to stop the DCF/2 │ │ │ │Control Processes. │ ├────────┼──────────────────────┼────────────────────────────────────────┤ │DCF2 │/V:CREATE /S: /F: │Creates VDU of /S:[size in megabytes] │ │ │ │and /F:[file specification] (The path │ │ │ │and filename for the VDU container │ │ │ │file.) │ ├────────┼──────────────────────┼────────────────────────────────────────┤ │DCF2 │/R:X │Refreshes the DCF2INFO file for VDU "X."│ │ │ │(Wait 15 seconds before typing the next │ │ │ │X:DCF2INFO.) │ └────────┴──────────────────────┴────────────────────────────────────────┘ ═══ 7.2.1. How to Add a VDU ═══ For the sake of example, we will use a hypothetical system having a physical drive C: with a logical partition D:. We have installed the DCF/2. During the installation, we created two VDUs. These are drives E: and F: In the example outlined below, we will add a third VDU to our hypothetical system. The third VDU will take the next available drive letter, G:. We'll create G: as a 100MB drive. The process involves three steps. First, we will use the DCF/2 Control Program to create the VDU. Second, we will make two changes to the DCF/2 statements in the CONFIG.SYS. Third, we will reboot or restart the computer. Create the VDU Container File To create the VDU, we will first change to the DCF2 program directory. Then, we will use the DCF2 /v:create command to create our 100MB VDU G: DCF2 /V:CREATE /S:100 /F:D:\DCF2\DCF2_G.VDU The parameters used above are /V: (Virtual Disk Unit), /S: (Size in MB) and /F: (Path and File Specification). Add the VDU Drive Letter We will edit the /:u pararmeter following the DCFPDD.SYS statement in the CONFIG.SYS file. The /:u is the total number of virtual disk units, i.e., VDU drive letters requested. To add one VDU drive letter, we will increase this number by 1. On our hypothetical system, the /u: parameter is currently the number 2. When we add the next VDU dirve letter, we increase this number by 1 -- from 2 to 3. DEVICE=C:\DCF2\DCF2PDD.SYS /u:3 At this point, we have a new drive letter, G:, but nothing points to it until we add an environment string to associate G: with the VDU container file. The environment strings in the CONFIG.SYS currently look like the following: SET DCF2_VDU_E=C:\DCF2\DCF2_E.VDU SET DCF2_VDU_F=D:\DCF2\DCF2_F.VDU If we want our new VDU G: to reside on D:, then its environment string or statement will look like this: SET DCF2_VDU_G=D:\DCF2\DCF2_G.VDU We save the changes to the CONFIG.SYS and exit the edit session. Restart the Computer The final step in the process is to restart the computer system. This initializes the changes made to the CONFIG.SYS and runs FORMAT on the new VDU. ═══ 7.2.2. How to Delete a VDU ═══ If we want to delete or remove the last VDU we created, the procedure involves four steps. First, we use the DCF2 program to stop the DCF2 control processes -- so that we can access the VDU. Second, we change the DCF2 statements in the CONFIG.SYS. Third, we delete the VDU container file. Fourth, we restart the computer to initiate the changes made to the CONFIG.SYS. Note: Deleting a VDU deletes all of the data stored in the VDU. Be sure to make a backup copy of any of the data you do not want to delete permanently before proceeding. Shut Down the DCF2 A VDU cannot be deleted while the DCF2 control processes are running. If you try to, you get an error message that the drive is in use by another process. To shut down the DCF2, first change to the DCF2 program directory. Then, use the either the DCF2 /A:SHUTDOWN or DCF2 /- command to stop the DCF2 control processes. DCF2 /A:SHUTDOWN Remove the VDU Drive Letter To remove the VDU drive letter, we edit the DCF/2 statements in the CONFIG.SYS. First, we look for the /u: parameter following the DCF2PDD.SYS and reduce the number by 1. Next remove from the CONFIG.SYS the SET statement which points to our last drive letter: SET DCF2_VDU_G=D:\DCF2\DCF2_G.VDU Finally, we save the changes to the CONFIG.SYS. and exit from the edit session. Delete the VDU Container File To protect you from inadvertantly deleting your VDU(s), we set the system attribute. As a result, if you DELETE *.* in the DCF2 directory, OS/2 does not delete the VDU(s). For OS/2's DELETE command to access a VDU, we must first remove this attribute: The OS/2 command used to remove the system attribute is: ATTRIB *.VDU -S Now, we can use the DELETE command to delete the VDU container file. In the case of the system described in the section on adding a VDU, the last VDU is G:. The following command would delete the file: DELETE DCF2_G.VDU Restart the Computer As always, changes to the CONFIG.SYS are only initialized after the computer is restarted. ═══ 7.2.3. How to Remove the DCF/2 ═══ If you want to remove the DCF/2 from your computer completely, the procedure is much the same as that for deleting a VDU (as described in the preceding section). Instead of deleting a single VDU, you delete all VDUs and the DCF/2 programs and DCF2 program directory as well. Instead of changing DCF/2 statements in the CONFIG.SYS, you remove all statements. Note: Deleting a VDU deletes all of the data stored in the VDU. Be sure to make a backup copy of any of the data you do not want to delete permanently before proceeding. The four steps in the procedure are: First to shut down the DCF2 control processes; second to delete the VDUs, DCF/2 programs and directory or directories; third to remove all of the DCF2 statements from the CONFIG.SYS; and fourth, to restart the computer system. Shut Down the DCF2 VDUs cannot be deleted while the DCF2 control processes are running. So, the first step is the shut down the DCF2. To shut down the DCF2, first change to the DCF2 program directory. Then, use the either the DCF2 /A:SHUTDOWN or DCF2 /- command to stop the DCF2 control processes. DCF2 /A:SHUTDOWN Delete DCF/2 Files Your VDUs may or may not be in the same DCF2 directory as are the DCF/2 program files. Before you can DELETE them, you must remove the OS/2 system attribute from the VDU(s), so that the OS/2 DELETE command will be able to access the files. For each host on which you placed one or more VDUs, change to the DCF2 directory, and use the following OS/2 command to remove the system attribute from the VDU(s): ATTRIB *.VDU -S Now, use the DELETE command to delete the VDU container file(s) and DCF/2 programs: DELETE *.* Finally, remove the DCF2 directory or directories: rd DCF2 Remove the DCF/2 Statements Next, edit the CONFIG.SYS file. All of the DCF/2 statements added to your CONFIG.SYS file are delimited by lines and marked with the date-time stamp for the change. The statements include: o Two DEVICE statements (DCF2PDD.SYS and DCF2CDE.SYS) o One SET statement for each VDU o One CALL statement at the end of your CONFIG.SYS Delete these, save the changes to the CONFIG.SYS and exit the edit session. Hint: If you have not made any changes to your CONFIG.SYS since installing the DCF/2, you can avoid having to edit the file manually. Instead, copy CONFIG.!D! to CONFIG.SYS to restore the file as it existed just prior to installing the DCF/2. Restart the Computer The last step is to initialize the changes made to the CONFIG.SYS by rebooting or restarting the computer. ═══ 7.3. Ancillary Control Process (DCF2ACP.EXE) ═══ Just as a physical disk unit has a controller, so do our virtual disks. The "ACP" is the virtual disk's controller. When the DCF2ACP is stopped, it is analogous to pulling your physical disk's controller out of your system box. You cannot access compressed data on a VDU if the DCF2ACP is not running. Any DCF/2 Ancillary Control Process error conditions are reported in the DCF2ACP.LOG file created in the root of your OS/2 boot drive. If you experience a problem, you may want to enable DCF2ACP logging and debugging to a greater degree. You can do so by removing the REM >> from the DCF2ACP logging statement in your CONFIG.SYS and rebooting. SET DCF2_ACP_LOGNG=3 SET DCF2_ACP_DEBUG=3 The DCF/2 takes advantage of the sophisticated caching mechanisms available with the High Performance File System. Anytime you write data to cache blocks -- whether using the DCF/2 of not -- there is the risk that it will be lost should the power to the machine be interrupted. We feel the performance benefit caching provides far out weighs this risk. But, just in case you do not share these sentiments, enter the following SET statement in your CONFIG.SYS: SET DCF2_ACP_MISSION_CRITICAL=1 ═══ 7.4. VDU Control Process (DCF2VCP.EXE) ═══ The DCF2VCP manages the virtual disk units you create using the controller (DCF2ACP). During system startup, the DCF2VCP initializes your VDUs and launches the DCF2ACP and Space Manager. Any DCF/2 VDU Control Process error conditions are reported in the DCF2VCP.LOG file created in the root of your OS/2 boot drive. If you experience a problem during system startup, you may want to enable DCF2VCP logging to a greater degree. You can do so by removing the REM >> from the DCF2VCP logging statement in your CONFIG.SYS and reboot. Or you can issue the following SET command: SET DCF2_VCP_LOGNG=3 SET DCF2_VCP_DEBUG=3 ═══ 7.5. LED Monitors (DCF2MON.EXE) ═══ The monitors are LED icons -- one for each VDU you create. They flash to indicate drive activity. Monitor LEDs flash red for write and blue for read operations. They flash green during compression and yellow during decompression. If you need to create a VDU LED manually, do the following: 1. Use the drives icon to open the DCF2 program directory. 2. Locate the DCF2MON.EXE icon in the DCF2 program directory. 3. Drag the icon to your Startup folder. (Control+Right Mouse Button) 4. Open the settings notebook for the icon. 5. Go to the parameters box on the program setting page. 6. Enter /l:X, where X is the VDU drive letter. 7. Close the settings notebook. 8. Double click on the VDU LED to put it on your desktop. You can move the icon to a specific location on your desktop and save that location so that when you restart your system, the icon retains its location. To do so, drag the icon to the desired location. Double click on the icon to close it. Reboot your system. The icon's location coordinates are now saved. You can make your VDU LEDs larger. Click the minimize button on the LED. The icon disappears from the desktop and reappears in your minimized window viewer -- bigger. Hint If you double click on an LED icon in your Startup Folder and the Window List pops up, look for the LED icon in your Minimized Window Viewer. The following are optional parameters for DCF2MON.EXE. and are specified in the parameters box in the LED icon's settings notebook on the program settings page. Parameter Function /l:X VDU Drive letter for this LED icon. /x: followed by a decimal value. Designates the x coordinate location of the LED icon on your Desktop. /y: followed by a decimal value. Designates the y coordinate location of the LED icon on your Desktop. /t: followed by time in seconds. Establishes the refresh frequency for the LED icon. Increase this if you feel the monitor refreshes are loading your system. (Applies to certain video adaptors.) /w Adds the monitor processes to the Window List ═══ 7.6. Shut Down Program ═══ As of Version 1.2, the DCF/2 shut down in completely integrated with OS/2's standard "right mouse button" shut down. If you have a DCF/2 System Shutdown icon on your desktop, please delete it. Whenever possible, use shut down before turning your computer off. By doing so, you insure that all of your VDUs are shut down properly and that the shut down process continues through the final Control-Alt-Delete box. You also bypass the CHKSDK /F (the DCF/2 automatically performs) on all drives found improperly shut down the next time your system boots OS/2. ═══ 7.7. Optimize Utility ═══ The Optimize Utility is not one you will run on a daily basis or even a weekly basis unless you feel it necessary to do so. Space occupied by files you have deleted from your VDU is only recovered by running the Optimize Utility (DCF2PAKR). The utility has two parts. The first (purge) concerns the deleted space on the VDU. It is necessary to run this part of the utility only if you have deleted a significant number of files from your VDU. The second part (optimize) recompresses the data stored on the VDU to its maximum compression. As result, the average compression ratio for the data stored in the VDU increases. The purge function is going to "touch" every byte of unused space on your VDU. If a problem occurs, run CHKDSK /F:3 on the VDU at your earliest convenience. Be aware, CHKDSK /F:3 can take a very long time. This is because it thoroughly checks all unused space on the disk. It is best to begin a CHKDSK /F:3 at the end of your work day. Note: Your VDU(s) and the programs and data on them are not available to you during the optimize process. The length of time required to optimize or recompact a VDU will vary with speed of your computer processor and the size of the VDU. Refer to the tables below to determine how much time to allow to recompact the VDU(s) on your computer system. To optimize a 200 MB Virtual Disk Unit with 190 MB in use on a 586/60 class machine will require 20-25 minutes. Since not all VDUs are created and optimized on a Pentium, the following table describes the estimated time required to optimize selected-size VDUs on a 486/66 class machine: Estimated Time Required to Optimize Your VDU ┌────────────┬──────────────────────────────────────┐ │VDU Size │Estimated Time to Complete │ ├────────────┼──────────────────────────────────────┤ │100 MB │15 minutes │ ├────────────┼──────────────────────────────────────┤ │200 MB │30 minutes │ ├────────────┼──────────────────────────────────────┤ │500 MB │75 minutes │ ├────────────┼──────────────────────────────────────┤ │1 GB │2 1/2 to 3 hours │ └────────────┴──────────────────────────────────────┘ In order to estimate the length of time recompacting the VDU(s) will require on your system, refer to the following table. 1K Chunks Optimized per Minute by Machine Class ┌──────────────────────┬──────────────────────────────────────┐ │Class of Machine │Minutes per 1K Chunks │ ├──────────────────────┼──────────────────────────────────────┤ │486/50 - 586/60 │1 minute per 1K chunks │ ├──────────────────────┼──────────────────────────────────────┤ │486/25 - 486/50 │3 minutes per 1K chunks │ ├──────────────────────┼──────────────────────────────────────┤ │386/33 │5 minutes per 1K chunks │ ├──────────────────────┼──────────────────────────────────────┤ │386/10 - 386/25 │Up to 10 minutes per 1K chunks │ └──────────────────────┴──────────────────────────────────────┘ Optimizing a VDU involves four steps: Purging the VDU(s), stopping the DCF2ACP, optimizing the VDU(s) and then restarting the DCF2ACP. Purging VDUs Purging removes deleted space from VDU(s) -- it does not remove your data. You purge a VDU prior to optimizing it only if you have deleted a significan number of files from the VDU. To purge VDU E: you use the following command in which the /P parameter means PURGE and /V: is following by the drive letter of the target VDU: DCF2PAKR /P /V:E Stopping the DCF/2 in Preparation to Optimize VDUs Before you can proceed to OPTIMIZE your VDUs, you must first stop the DCF2ACP. To do so, use the following command: DCF2 /A:SHUTDOWN Remember, your VDUs and the data on them will not be available until you restart the DCF2ACP. Optimizing VDUs The OPTIMIZE process will recompress each chunk of compressed data stored in the VDU to its maximum compression. To optimize VDU E: you use the following command in which the /O parameter means OPTIMIZE and /V: is following by the drive letter of the target VDU: DCF2PAKR /O /V:E Starting the DCF/2 Once the OPTIMIZE program completes, you need to restart the DCF/2 control processes in order to access the data on you VDUs. From the DCF2 program directory, execute the DCF2 control program command: DCF2 /A:STARTUP Converting DCF/2 Version 1.1a to Version 1.2 Format Users with existing VDUs formatted under DCF/2 Version 1.1a should refer to the appropriate appendix for the procedure to follow in order to convert VDUs created using version 1.1a to the format used in version 1.2. ═══ 7.8. DCAT (Disk Compression Analysis Tool) ═══ The DCF/2 comes with a powerful and easy-to-use utility which allows you to analyze the data on a selected physical or logical drive in terms of the average compression ratio and the amount of space recoverable by storing that data on a DCF/2 virtual disk. The DCF/2 installation program placed a DCAT icon on your desktop. The DCAT or Disk Compression Analysis Tool is an interactive, OS/2 Presentation Manager application, with full online help (F1, or HELP button). To run the DCAT, change to the DCF2 program directory and type: DCAT. ═══ 7.9. Moving Files from Physical to Virtual Space ═══ You can use any of your existing DOS, Windows, or OS/2 program utilities to move, copy, delete, and maintain your DCF/2 VDU files. NOTE: Some applications (e.g., FaxWorks for OS/2) load device drivers from DEVICE statements in your CONFIG.SYS file. If the PATH for the device driver points to a virtual disk unit that is not yet available, OS/2 will report the DEVICE not found. For these applications, move the applications to a virtual disk unit, but leave the application's device drivers on the physical disk unit in an identical subdirectory. Using XCOPY and DELETE When using XCOPY to copy files into a VDU, it is recommended that you include the '/f' and '/e' command line switches to insure that the existing file extended attributes are copied from the physical disk unit. See the OS/2 online help for XCOPY for additional switches. Using the Drives Icon The OS/2 DRIVES icon provides you with a powerful Presentation Manager utility which not only copies and moves your files between physical and compressed virtual disk storage, it simultaneously updates your DESKTOP objects so that they reflect the necessary drive letter changes, too! Be aware, when moving program objects, that there may be LIBPATH, PATH, and DPATH references to those program objects which may not be updated. If you have very little physical space available on the host and use the drives icon, be careful. The drives icon move seems to move files in large chunks, first copying and then deleting them from their original location. This can cause you to run out of physical space on the host drive and may cause OS/2 to trap. Go slowly. Hint : Including applications stored on a VDU in the LIBPATH statement in your CONFIG.SYS is somewhat problematic. If the AutoCheck function hasn't completed and your VDUs are not yet available to OS/2, it can cause the system to lock up. The workaround is to create the identical subdirectory on a physical disk unit and move all of the program in questions DLLs to the subdirectory on the PDU. Then change the LIBPATH to point to the subdirectory on the PDU. ═══ 8. VDU Maintenance ═══ Because of the auto-checking built into the DCF/2 startup process, you won't normally need to spend a great deal of your time checking your physical and virtual space. The following topics are covered in this section: o Checking Physical Space o Checking Virtual Space ═══ 8.1. Checking Physical Space ═══ THE CARDINAL RULE FOR VDU MAINTENANCE IS: ALWAYS RUN CHKDSK ON THE PHYSICAL DRIVE FIRST. If you suspect that the VDU's physical or host drive is corrupted, you MUST run CHKDSK (FAT) or CHKDSK /F (HPFS) on the physical drive to prevent damaging the VDU. You will use CHKDSK on FAT-based physical disk units and CHKDSK /F on HPFS-based physical disk units. If you are unfamiliar with this program, please refer to OS/2's online help. ═══ 8.2. Checking Virtual Space ═══ Because a VDU looks physical to OS/2, it requires no special utilities beyond those supplied with OS/2. In this case, that is the CHKDSK program. The program will correct any space allocation errors and remove any corrupted files in the VDU, placing them in the FOUND directory as ".CHK" files. Run CHKDSK /F on your VDUs only after you have CHKDSK'ed the physical or host drive or are absolutely certain that the host drive is "clean." If you are unfamiliar with this program, please refer to OS/2's online help. The DCF2INFO file for each VDU reports both the current compression ratio for the VDU and the estimated compression ratio after the next recompaction or optimize. As you use your VDUs, you will notice the average compression ratio for the data stored on a VDU begin to drop. Once a week to once a month -- or as you feel it necessary -- run the DCF2PAKR program on each of your VDUs to purge them of deleted space and optimize them. During this process each chunk of data stored in the VDU is recompressed. Generally, you will recover about 10% of the space in use on the drive. The process involves four steps: The first step zeros out deleted and lost space on the drive. We call this "purging." It does not purge data from your VDU -- only free space. The DCF2 must be running during the purge function. Once the purge function is complete, the second step is to stop the DCF2. The third step is to optimize the drive. This decompresses and recompresses each chunk of data on your VDU. The fourth step is to restart the DCF2. 1. Purge your VDU of deleted space using the DCF2PAKR command: DCF2PAKR /p /v:x 2. Stop the DCF2 using the DCF2 command: DCF2 /A:Shutdown 3. Optimize your VDU using the DCF2PAKR command: DCF2PAKR /o /v:x 4. Restart the DCF2 using the DCF2 command: DCF2 /A:Startup The commands are executed from an OS/2 window or full screen, in the DCF2 program directory. In the above example, the DCF2PAKR command options are: /p (purge), /v:x (the VDU drive letter to be purged, e.g. VDU X) and /o (optimize). You can create a batch file to purge and optimize your VDU(s) and launch it from OS/2's ALARMS applet or from a commercial package like Sundial's RELISH for OS/2. Just remember to purge all VDUs before you shut down the DCF2. Then, optimize all VDUs before starting the DCF2 again. For additional information please refer to the section in the User Reference on the "Optimize Utility." ═══ 9. Troubleshooting ═══ The following sections describe the most common problems and what to do. The first rule is: Don't panic. Using the tools you have on hand, you can recover from almost any situation. The topics covered include: o Logfiles o Installation Fails o VDU Drive Letter Incorrect o VDU Does Not Autoformat o Long Low Beep-Beep During Initialization o System Hangs o Drive Inconsistencies o Root Directory Not Found o VDU Appears to be Out of Space o DCF/2 Sings o Shut Down Doesn't Work o Miscellaneous o Contacting Technical Support ═══ 9.1. Logfiles ═══ The first place to look to diagnose the cause of a suspected problem is the logfiles, DCF2ACP.LOG and DCF2VCP.LOG in the root of your boot drive. These logfiles are created automatically by the DCF/2. If you delete them -- which you will want to do from time to time -- they will be recreated the next time you startup the DCF/2. In some cases, you may need more detailed log information. When you installed the DCF/2, it installed in your CONFIG.SYS file logging and debug statements for both the DCF2ACP and DCF2VCP. To enable logging permanently, you can remove the REM from in front of eitiher or both of the statement(s). SET DCF2_ACP_LOGNG=3 SET DCF2_ACP_DEBUG=3 Before calling for technical support, please have a copy of the DCF2ACP.LOG and the DCF2VCP.LOG available. You may be asked to fax a copy of it to us. If the file covers several days, it will not be necessary to send all of the pages -- usually the last few entries will be all that are necessary. ═══ 9.2. Installation Fails ═══ If you installed the DCF/2 from a temporary directory on your hard drive, make sure the name of the temporary directory is not "DCF2." If it is, make a new temporary directory using some other name (e.g.,D:\tmp), copy the files to the new directory and delete the old one. Run the DCF/2 installation program from the new temporary directory. ═══ 9.3. VDU Drive Letter Incorrect ═══ The first VDU will take the first physical drive letter available on your system. Remember that network drives are logical not physical. If network drives are enabled when the DCF/2 installation program is run, the first VDU will take an incorrect drive letter. For example, say your system has a physical drive C:, logical D:, network drive E: and F:. The DCF/2 would assume that the first available drive letter is G: rather than E:. If you have LAN software running, you need to logoff prior to running the DCF/2 installation program. If you have completed the installation process and only later realized that you had not logged off of your network, you can make the necessary changes to correct the drive letter manually. Do the following: 1. Edit the VDU's SET statement in your CONFIG.SYS file to reflect the correct drive letter if it does not. 2. Change to the DCF2 program directory. Remove the system attribute from the VDU file: ATTRIB *.VDU -S 3. Rename the VDU file to match that of its environment statement in the CONFIG.SYS 4. Reboot the system. Return to the example of the system with physical C: and logical D:, on which the first VDU should be E: and the second F: -- but, because we hadn't logged off of the network before running the DCF/2 installation program, the first VDU took drive letter G: and the second H:. The incorrect statements inserted in the CONFIG.SYS look like this: DEVICE=C:\DCF2\DCF2PDD.SYS /u:2 SET DCF2_VDU_G=C:\DCF2\DCF2_G.VDU SET DCF2_VDU_H=D:\DCF2\DCF2_H.VDU First, we edit each SET statement in the CONFIG.SYS to reflect the correct drive letters, E: and F: and save the changes. The corrected statements look will this: SET DCF2_VDU_E=C:\DCF2\DCF2_E.VDU SET DCF2_VDU_F=D:\DCF2\DCF2_F.VDU Next, we change to the DCF2 program directory on drive C: and remove the system attribute from the VDU: ATTRIB *.VDU -S Now, we rename the file: RENAME DCF2_G.VDU DCF2_E.VDU We repeat the above two steps for the second VDU -- changing to the DCF2 directory on D:, removing the system attribute and renaming the file to be, in this case, DCF2_E.VDU. Finally, we reboot the system to initiate the changes we've made. ═══ 9.4. VDU Does Not Autoformat ═══ Each VDU must have an environment statement in the CONFIG.SYS file which provides the full path for the VDU's container file. If this statement is missing or incorrect, the DCF/2 cannot find the file. This situation is most likely to occur if you create additional VDUs after having run the DCF/2 installation program and forget to either increment the u: number following the DCF2PDD.SYS or to add an environment statement for the VDU. (Check, too, for typographical errors.) Check to make sure that the environment statement does in fact exist and that the drive association is correct, i.e., it points to a valid file. You can do this by looking at the statements the install program placed in your CONFIG.SYS file, or you can use the following OS/2 command: SET In either case, your should find a statement that resembles the following for each VDU: SET SET DCF2_VDU_X=[host drive letter]:\DCF2\DCF2_X.VDU In the above statement, X is the VDU's drive letter. Refer to the foregoing example, if you find you have made a mistake and need to correct the either the VDU's file name and/or environment statement(s). ═══ 9.5. Long Low Beep-Beep During Initialization ═══ The DCF2PDD.SYS places a lock on its shared memory. This signal means that the lock has failed. Reports seem to indicate that OS/2's memory allocation during system startup can be timing sensitive. The solution is to either move the DCF/2's CALL= statement from the end of your CONFIG.SYS file to your STARTUP.CMD, or to reduce the cache sizes for either or both the HPFS cache and the FAT diskcache. In some cases, the order in which various DEVICES load in the CONFIG.SYS can affect OS/2's memory allocation during startup. Since systems differ, you may find it helpful to experiment with the order in which DEVICES load on your system. ═══ 9.6. System Hangs ═══ If your system fails to startup correctly, i.e., it hangs before or during VDU initialization, or as the workplace shell loads, do the following: 1. Reboot the system. 2. When you hear the first set of "bleep-bleeps," hold down the CONTROL key to launch an OS/2 command processor. 3. Change to the DCF2 program directory. 4. Use the DCF2PAKR to optimize and repair any VDU's in question. Use the following command -- replacing the X with the drive letter of the VDU to be optimized: DCF2PAKR /O /V:X 5. Repeat step 4. for each VDU. 6. Type: EXIT System startup will continue. The VDUs should initialize and all should be back in order. If problems persist, check the DCF2ACP.LOG file in the root of your boot drive. ═══ 9.7. Drive Inconsistencies ═══ The prescribed remedy whenever you suspect a problem is to do the following: 1. Run CHKDSK /F:2 on the physical host drive three times. (You may need to do this from floppy.) 2. Run CHKDSK /F:3 on the physical host drive at least one time. (Twice, maybe.) 3. Startup the DCF/2 and repeat steps 1. and 2. for each virtual disk unit. Because of the time involved, you may want to write a simple batch file, e.g. CHKVDU_M.CMD, that you can run at night. It might look like the following: @echo off chkdsk m: /f chkdsk m: /f chkdsk m: /f chkdsk m: /f:3 chkdsk m: /f:3 exit ═══ 9.8. Root Directory Not Found ═══ Do not panic. This occurs infrequently -- generally after a severe system crash. Allow CHKDSK /F to run and repair any damage. In some cases, this has been known to take several hours. Because of the "iterative" nature of the program, you should then run it again and again until it no longer reports errors. You may have some work to do to rename the FOUND* directories and CHECK files, but your VDU will be intact. In extreme cases, it may be necessary to restart or reboot your computer system. We have had instances where it looked as if a drive had been lost only to restart the system and find it still there and intact. Following the CHKDSKs, stop the DCF/2 control processes and run the DCF2PAKR /O to recompress all of the data stored on the VDU. Do not run the DCF2PAKR /P option to purge the VDUs of empty space first. ═══ 9.9. VDU Appears to be Out of Space ═══ Virtual space is managed so that, when you do a directory of the VDU, what you see correctly reflects the estimated amount of virtual space available. Each VDU has a DCF2INFO.CMD file, which is adjusted dynamically based upon the average compression ratio of the data in the VDU and the amount of physical space available on its host drive. Whenever an abnormal shut down occurs, the OS/2 CHKDSK /F program is automatically run as the system boots OS/2. It has been known to remove a corrupted DCF2INFO.CMD file and place it in a FOUND directory. The DCF2INFO.CMD file may appear very large to OS/2. The result is that your system appears out of space. If you suspect that CHKDSK has, in its infinite wisdom, placed a renamed copy of your VDU's DCF2INFO.CMD space management file in one of these FOUND directories, find it and delete it. ═══ 9.10. DCF/2 Sings ═══ The DCF/2 comes "audio-enabled." The sounds mean different things. Unlicensed Copy If this copy of the DCF/2 is an unlicensed copy -- one not purchased -- it will "sing". This audible signal is our gentle reminder that this copy of the DCF/2 is unlicensed. While we wish to give those who feel they need an opportunity to "try before you buy," the opportunity to do so, the DCF/2 is neither "shareware" nor "freeware" but licensed software. To license it, one must purchase it. See the second page of the REMINDER.LOG generated in your in the root directory of your boot drive for information on both temporarily disabling the sounds and purchasing the DCF/2. If your licensed copy of the DCF/2 continues to sing, we apologise. Please contact technical support at your earliest convenience. Beep-Beep at Startup As the system starts up a series of beep-beeps signal that the keyboard is enabled to capture a user entered SHIFT or CONTROL in order to abort or interrupt the DCF/2 loading process. These can be disabled using by adding the /q (must be in lowercase) parameter to the CALL= statement in your CONFIG.SYS. The line might look like the following: CALL=C:\DCF2\DCF2.EXE /A:STARTUP /q ═══ 9.11. Shut Down Doesn't Work ═══ If your system does not shut down through the final C-A-D box, check to see if there are any *.new files in your OS2\DLL subdirectory. If there are, you need to rename them manually by doing the following: 1. Reboot. 2. Use the CONTROL key to interrupt the DCF/2 load and launch an OS/2 command processor. 3. Use the OS/2 copy command to rename the files: Copy OS2\DLL\*.NEW OS2\DLL\*.DLL 4. Delete the *.NEW files 5. Continue system startup. Type: EXIT ═══ 9.12. Miscellaneous ═══ If you are running 4OS2, make sure you are running the most current version. Older versions of 4OS2 have been known to produce strange messages. Some users have reported problems shutting down when using 4OS2. If you find that your system is not shutting down correctly, check for any "*.new" files in your OS2\DLL subdirectory and rename them *.DLL. To do so by: 1. Reboot. 2. Use the CONTROL key to interrupt the DCF/2 load and launch an OS/2 command processor. 3. Use the OS/2 copy command to rename the files: Copy OS2\DLL\*.NEW OS2\DLL\*.DLL 4. Delete the *.NEW files 5. Continue system startup; type: EXIT ═══ 9.13. Contacting Technical Support ═══ Telephone technical support is available to registered users only. Please have your license number handy as well as a copy of the DCF2ACP.LOG file if appropriate. Telephone technical support is available Monday through Friday and is reached by calling (717) 698-8300 between 8 a.m. to 4 p.m Eastern Time. Online technical support is available to both registered and unregistered users through the Proportional Software OS2BBS CForum (OS2DCF2 via IBM TalkLink and Advantis) and through the Proportional Software Vendor Forum on CompuServe (GO OS2AVEN). ═══ 10. Glossary of Terms ═══ The glossary provides definitions for commonly used terms. On-the-fly Data Compression An on-the-fly data compression product creates a special file, which serves as a container for compressed data. When the an application requests data stored in this way, the data is automatically compressed or decompressed "on-the-fly." The user does not have to execute a command to "unzip" or "unpak" the data requested. Virtual Disk Unit or VDU "Virtual Disk Unit" is the term we use to describe a DCF/2 compressed drive. It looks like a "real" or "physical" drive to OS/2. Target Drive The target drive is the uncompressed drive to which the DCF/2 program files are copied during the installation and from which OS/2 runs DCF/2 programs. Host Drive The host drive is the physical drive on which a DCF/2 "Virtual Disk Unit" or VDU resides. DCF/2 Ancillary Control Process (DCF2ACP) Just as a physical disk unit has a controller, so do our virtual disks. The "ACP" is the virtual disk's controller. When the DCF2ACP is stopped, it is analogous to pulling your physical disk's controller out of your system box. You cannot access compressed data on a VDU if the DCF2ACP is not running. DCF/2 VDU Control Process (DCF2VCP) The DCF2VCP manages the virtual disk units you create using the controller (DCF DCF/2 Space Manager One of the most important functions of the VDU Control Process (DCF2VCP) is spa management for each of your VDUs. DCF2VCP monitors the amount of space available on each VDU's host drive and prevents the VDU from running out physical space. "Dirty" The term "dirty" is used to describe the state of a physical or virtual drive w the drive was shutdown by a means other than running the DCF/2 shutdown program. Typically, this happens if you switch off the computer without running shutdown first. It can happen as the result of a power failure or brownout. It can also happen as the result of an operating system trap or hang. A drive that is "dirty" must be CHKDSKed prior to its being available for use. DAT The DAT is the Disk Allocation Table. The DAT records the location of each compressed or stored chunk, as well as free space available, on the VDU. DTE A DTE is an entry in the Disk Allocation Table. FLE An FLE is a Free List Entry. Free list entries identify spaces in the VDU that are available. To check the number of FLEs on a VDU, use the X:D When you run the DCF2PAKR /P operation, these are zeroed out. The space is then available to be recovered during the DCF2PAKR /O operation. FLT An FLT is a Free List Table or a table of FLEs for a VDU. To check the number of FLTs on a VDU, use the x:DCF2INFO command. When you run the DCF2PAKR /O utility, all but one of the FLTs is removed from the drive. ═══ 11. Appendix ═══ The Appendix contains the following sections: o DCF/2 Command Reference o Converting Version 1.1a to Version 1.2 o Tip & Techniques o Cache Considerations o 20 Questions About DCF/2 o Trademarks, Copyrights, & Acknowledgements ═══ 11.1. DCF/2 Command Reference ═══ Listed below are the commands available for the following DCF/2 programs: o Control Program (DCF2.EXE) o Optimize Utility (DCF2PAKR.EXE) o Monitor Program (MONITOR.EXE) ═══ 11.1.1. Control Program (DCF2.EXE) ═══ DCF2ControlProgramCommandLineParameters ┌────────┬──────────────────────┬────────────────────────────────────────┐ │Command │Parameter │Function │ ├────────┼──────────────────────┼────────────────────────────────────────┤ │DCF2 │/A:STARTUP │Starts the DCF/2 Control Processes. │ │ │ │Makes your VDUs available. │ ├────────┼──────────────────────┼────────────────────────────────────────┤ │DCF2 │/+ │"Shorthand" method to start the DCF/2 │ │ │ │Control Processes. │ ├────────┼──────────────────────┼────────────────────────────────────────┤ │DCF2 │/A:STARTUP/q │Starts the DCF/2 Control Processes │ │ │ │without beeps signaling "keyboard │ │ │ │enabled." │ ├────────┼──────────────────────┼────────────────────────────────────────┤ │DCF2 │/A:STARTUP/Q │Starts the DCF/2 Control Processes │ │ │ │without beeps signaling "keyboard │ │ │ │enabled" and without writing the DCF/2 │ │ │ │startup messages to the screen. │ ├────────┼──────────────────────┼────────────────────────────────────────┤ │DCF2 │/A:STARTUP/T:n │Starts the DCF/2 Control Processes with │ │ │ │a count-down of n seconds. This is the │ │ │ │interval during which the keyboard is │ │ │ │enabled to accept a user entered SHIFT │ │ │ │or CONTROL key to to interrupt the │ │ │ │DCF/2's load process. │ ├────────┼──────────────────────┼────────────────────────────────────────┤ │DCF2 │/A:Startup /D │Starts the DCF/2 Control Processes and │ │ │ │says to delete the DCF2INFO.CMD at │ │ │ │startup. Use this option if you run │ │ │ │virus scanning software. It will │ │ │ │eliminate uncecessary scanning time. │ ├────────┼──────────────────────┼────────────────────────────────────────┤ │DCF2 │/A:STATUS │Reports the Status of the DCF/2 Control │ │ │ │Processes (currently running or │ │ │ │currently not running). │ ├────────┼──────────────────────┼────────────────────────────────────────┤ │DCF2 │/A:SHUTDOWN │Stops the DCF2 Control Processes. Your │ │ │ │VDUs are unavailable when you stop the │ │ │ │DCF/2. Use this command before you │ │ │ │OPTIMIZE a VDU or if you need to delete │ │ │ │a VDU. │ ├────────┼──────────────────────┼────────────────────────────────────────┤ │DCF2 │/- │"Shorthand" method to stop the DCF/2 │ │ │ │Control Processes. │ ├────────┼──────────────────────┼────────────────────────────────────────┤ │DCF2 │/V:CREATE /S: /F: │Creates VDU of /S:[size in megabytes] │ │ │ │and /F:[file specification] (The path │ │ │ │and filename for the VDU container │ │ │ │file.) │ ├────────┼──────────────────────┼────────────────────────────────────────┤ │DCF2 │/R:X │Refreshes the DCF2INFO file for VDU "X."│ │ │ │(Wait 15 seconds before typing the next │ │ │ │X:DCF2INFO.) │ └────────┴──────────────────────┴────────────────────────────────────────┘ ═══ 11.1.2. Optimize Utility (DCF2PAKR.EXE) ═══ Note: If multiple VDUs are to be optimized, purge each VDU BEFORE issuing the command to optimize the VDUs. The DCF2 must be running for the purge operation and must NOT be running for the recompression or optimize operation. DCF2PAKRCommandLineParameters ┌──────────┬────────────────────┬────────────────────────────────────────┐ │Command │Parameter │Function │ ├──────────┼────────────────────┼────────────────────────────────────────┤ │DCF2PAKR │/P /V:X │Purges VDU X, where "X" is the VDU's │ │ │ │drive letter. The DCF2 must be running.│ ├──────────┼────────────────────┼────────────────────────────────────────┤ │DCF2PAKR │/O /V:X │Optimizes VDU X, where "X" is the VDU's │ │ │ │drive letter. Before "optimizing", │ │ │ │shutdown the DCF2. │ └──────────┴────────────────────┴────────────────────────────────────────┘ ═══ 11.1.3. Monitor Program (MONITOR.EXE) ═══ The DCF2MON.EXE program includes optional parameters that can either be used from an OS/2 command line or set using the VDU LED icon's Settings Notebook on your Desktop. These are: MONITOR . EXECommandLineParameters Parameter Function /l:X VDU Drive letter for this LED icon. /x: followed by a decimal value. Designates the x coordinate location of the LED icon on your Desktop. /y: followed by a decimal value. Designates the y coordinate location of the LED icon on your Desktop. /t: followed by time in seconds. Establishes the refresh frequency for the LED icon. Increase this if you feel the monitor refreshes are loading your system. (Applies to certain video adaptors.) /w Adds the monitor processes to the Window List. ═══ 11.2. Converting Version 1.1a to Version 1.2 ═══ Before you can use DCF/2 Version 1.1a VDU's with Version 1.2, you must follow the procedure outlined below to "convert" them. 1. Backup your 1.1a VDU before installing the DCF/2 1.2. 2. Do not use the "Update/Register" option on the installation menu. Do a full install according to the following steps: a. REM out all DCF/2 1.1a statements in your CONFIG.SYS file. b. Rename any existing DCF/2 VDUs to names other than DCF2_X.VDU, (e.g., DCF2_X.11A); so that the install program does not delete it. c. Reboot your computer system. d. Install the DCF/2 Version 1.2. e. Reboot your computer system -- the install program will do this for your. 3. Let the DCF/2 startup normally. 4. Go to an OS/2 command prompt and change to the DCF/2 program directory. 5. Use a SET statement to point to your version 1.1a VDU: SET DCF2_VDU_X=DCF2_X.11a. 6. Stop the DCF/2 using the command, DCF2 /A:SHUTDOWN. 7. Use the DCF2PAKR program to decompress and then recompress the data in the VDU: Type DCF2 /O /V:X, where "X" is the VDU's drive letter. 8. Your Version 1.1a VDU is now reformatted for Version 1.2 usage. Note: The conversion takes approximately 1 minute per 1K chunks of data. Do not interrupt interrupt the DCF2PAKR program or the VDU will be lost. ═══ 11.3. Tip & Techniques ═══ The following Tips & Techniques for using the DCF/2 were contributed by people who use the DCF/2. o Updating the HPFS.IFS on Your OS/2 Disk 1 o Creating a Maintenance Partition o Loading Devices from the CONFIG.SYS o Using the DCF/2 on Laptops o Using the DCF/2 on Read/Write or Magneto Optical Drives o Using an Alternative Startup o Using the DCF/2 and Netware o Hints for Running Your Applications from a VDU ═══ 11.3.1. Updating the HPFS.IFS on Your OS/2 Disk 1 ═══ If you need to boot from the OS/2 install diskettes for a manual CHKDSK of the physical drives, copy the HPFS.IFS from the DCF/2 distribution disk to your OS/2 disk 1 before running CHKDSK. You MUST run CHKDSK from diskette using the same HPFS.IFS as you are running on your system. Remember, that during the DCF/2 installation, the install program may have updated your HPFS.IFS. If the date and time stamp of this file is later than that of the HPFS.IFS on your OS/2 disk 1, replace the HPFS.IFS on your Disk 1. The date and time of the file rather than the size is the key. ═══ 11.3.2. Creating a Maintenance Partition ═══ While you may never need one, should "disaster strike" (DCF/2 or otherwise), you won't regret time you spent creating a small -- 3MB, for example -- maintenance partition. Include on your maintenance partition a small editor should you need it to edit your CONFIG.SYS. Also include CHKDSK.COM, UHPFS.DLL and HPFS.IFS (make sure these are the versions currently in use on your system), so that CHKDSK exercises on the "normal" partition can be performed. If you have access to CompuServe, you may want to download BOOTOS.ZIP from OS2USER, Library 17 (also EWS). The file is intended for those in need of a bit of assistance when creating a maintenance partition. ═══ 11.3.3. Loading Devices from the CONFIG.SYS ═══ Device drivers which are loaded during the processing of the CONFIG.SYS prior to the DCF2PDD.SYS, should not be stored on a VDU. ═══ 11.3.4. Using the DCF/2 on Laptops ═══ In the following example, we describe a laptop system with a single hard drive having one primary and one logical partition. When docked, the system also has a CD-ROM device. The user wants to create 2 VDUs using the DCF/2. The VDUs need to retain the same drive letters -- regardless of whether the system is docked or portable. The solution is the create an additional "dummy" VDU to hold the place of the CD-ROM when portable. The procedure is as follows: o If installing the DCF/2 for the first time, use the DCF/2 installation program to create a total of 3 VDUs -- two "real" compressed drives and one to serve as a placeholder for the CD-ROM. The statements in the CONFIG.SYS look like this: DEVICE=C:\DCF2\DCF2PDD.SYS /U:3 DEVICE=C:\DCF2\DCF2CDE.SYS SET DCF2_VDU_E=C:\DCF2\DCF2_E.VDU SET DCF2_VDU_F=C:\DCF2\DCF2_F.VDU SET DCF2_VDU_G=D:\DCF2\DCF2_G.VDU o If the DCF/2 is already installed (and the installation was run which the system was in the docking station), use the DCF2 V:CREATE command to create the "dummy" VDU. The command syntax is: DCF2 /V:CREATE /S:[size in megabytes] /F:[full file specification] o To create a VDU of 1 MegaByte residing on "host" drive C:, the command would be: DCF2 /V:CREATE /S:1 /F:C:\DCF2\DCF2_E.VDU o When docked, the real VDUs will be F: and G: There will also be a third VDU, drive H: The path for this VDU should point to the "dummy" VDU. So that it does so, add the following SET statement to the CONFIG.SYS: SET DCF2_VDU_H=C:\DCF2\DCF2_E.VDU o Once the computer system is rebooted, the changes to the CONFIG.SYS file will be in effect and any unformatted. o When docked, the SET DCF2_VDU_E statement is ignored, the CD-ROM is E:. The user's real VDUs are F: and G: both when the system is in the docking station and when it is running portable. ═══ 11.3.5. Using the DCF/2 on Read/Write or Magneto Optical Drives ═══ In the event of an improper shutdown (loss of power, trap, hang, etc.) for the case in which the VDU host is an Read/Write or Magneto Optical, do the following: 1. Take the media out of the drive on startup. 2. Let the DCF/2 AutoCheck run. 3. From an OS/2 Command Processor, change to the DCF2 program directory and shutdown the DCF2ACP. Use the command, DCF2 /- or DCF2 /A:SHUTDOWN. 4. Put the media in the drive and do CHKDSK /F on the physical media. 5. From an OS/2 Command Processor, change to the DCF2 program directory and startup the DCF2ACP. Use the command, DCF2 /+ or DCF2 /A:STARTUP. 6. Let the DCF/2 AutoCheck run. ═══ 11.3.6. Using an Alternative Startup ═══ Use RESTART=EVERYTHING in your CONFIG.SYS. If you don't want everything restarted for some reason, use CTRL+SHIFT+F1 as soon as the desktop first appears to stop everything (including the DCF/2) from restarting. (You can let go of the keys when all icons appear.) This also suppresses the objects in the startup folder from starting. Create a .CMD file, which contains the DCF2 /A:Startup command. Place a program object pointing to the .CMD in your STARTUP folder. ═══ 11.3.7. Using the DCF/2 and Netware ═══ If your VDU host is a Netware file server volume, the following tips should be helpful. 1. Run your Netware login from the CONFIG.SYS using "CALL=x:\Netware\login.exe". Place this CALL statement AFTER the block of Netware statements and BEFORE the "CALL=x:\DCF2\DCF2.EXE /A:STARTUP." 2. Shutdown the DCF/2 BEFORE logging out. The login-logout process can be automated using a REXX command procedure like the one that follows. 3. Network-based VDUs are not shareable by two or more workstations at the same time. They can be accessed serially. 4. A Netware-based VDU is a good place to keep personal data, but not recommended for storing Netware login, logout and other utilities. Sample REXX Command to Synchronize Login and Logout /* Netware login / logout */ PARSE UPPER SOURCE . . progName progName = FileSpec('Nane',progName) PARSE ARG args /* Shutdown DCF/2 in preparation for logout */ 'd:\dcf2\dcf2.exe /a:shutdown' SELECT WHEN progName = 'LOGIN.CMD' THEN 'd:\netware\login.exe args WHEN progName = 'LOGOUT.CMD' THEN 'd:\netware\logout.exe' OTHERWISE SAY 'Program name must be LOGIN.CMD or LOGOUT.CMD' END /* Startup DCF/2 now that drives have been remapped */ 'd:\dcf2\dcf2 /a:startup' EXIT For initial startup, use the CALL statement in the CONFIG.SYS. Then use the above sample program or one like it for subsequent logins and logouts. You can make two copies of the sample program -- name one LOGIN.CMD and the other LOGOUT.CMD. You may need to copy the login.exe and logout.exe programs to a local drive. ═══ 11.3.8. Hints for Running Your Applications from a VDU ═══ Each application you run has a personality and quirks all its own. We have tested a wide variety of DOS, Windows and OS/2 applications. For most of them, the transition from physical to virtual is effortless. They run from a virtual drive just as they did from a physical one. The following is a collection of hints contributed by DCF/2 users, based on their experiences with some of the more finicky applications. AmiPro 3.0a AmiPro style sheets seem to want to load from a physical disk. Not allowing them to do so can result in a SYS3175 error. Workaround: Move all of AmiPro to the VDU, but make sure that the style sheet directory is on a physical disk. Then modify AMIUSER3.INI (use AmiPro's INIEDIT.EXE), so that the INI entry for the style sheet directory points to the right place. FaxWorks The FaxWorks device driver loads before the DCF/2 starts up. As a result, if it is on a VDU, the device is not found. Workaround: Load FaxWorks FMD.SYS from a physical drive. Communications Manager/2 If Communications Manager/2 (and any number of other programs which add statements to your CONFIG.SYS) is installed after the DCF/2, edit your CONFIG.SYS so that the last statement in the file is the CALL=x:\DCF2\DCF2.EXE /A:STARTUP. In the case of Communications Manager/2, this will preclude its startup process from interferring with that of your VDUs. ═══ 11.4. Cache Considerations ═══ Select from the tables below based upon whether your system is HPFS-only, FAT-only, Both with HPFS Active and FAT Passive or Both with HPFS Passive and FAT Active. For our purposes, "active" and "passive" are descriptors for the way a partition is used. If it is seldom used, consider it "passive." If a lot of disk intensive I/O occurs on the partition, consider it "active." Case 1: HPFS Partitions Only ┌──────┬──────┬──────────┬────────┬──────────┬──────────┬────────────────────┐ │RAM │CACHE │LAZY │MAXAGE │DISKIDLE │BUFFERIDLE│Other │ │ │ │WRITES │ │ │ │ │ ├──────┼──────┼──────────┼────────┼──────────┼──────────┼────────────────────┤ │16MB │2048 │/LAZY:on │40000 │30000 │20000 │REM out DISKCACHE │ │ │ │ │ │ │ │statement │ ├──────┼──────┼──────────┼────────┼──────────┼──────────┼────────────────────┤ │12MB │1536 │Same │Same │Same │Same │Same │ ├──────┼──────┼──────────┼────────┼──────────┼──────────┼────────────────────┤ │8MB │1024 │Same │Same │Same │Same │Same │ └──────┴──────┴──────────┴────────┴──────────┴──────────┴────────────────────┘ Case 2: FAT Partitions Only ┌──────┬──────┬──────────┬────────────────────────────────────────────────┐ │RAM │CACHE │LAZY │Other │ │ │ │WRITES │ │ ├──────┼──────┼──────────┼────────────────────────────────────────────────┤ │16MB │2048 │/LW │REM out the HPFS.IFS statement │ ├──────┼──────┼──────────┼────────────────────────────────────────────────┤ │12MB │1536 │Same │Same │ ├──────┼──────┼──────────┼────────────────────────────────────────────────┤ │8MB │1024 │Same │Same │ └──────┴──────┴──────────┴────────────────────────────────────────────────┘ Case 3: HPFS and FAT with HPFS Active ┌──────┬──────┬──────────┬────────┬──────────┬──────────┬────────────────────┐ │RAM │CACHE │LAZY │MAXAGE │DISKIDLE │BUFFERIDLE│DISKCACHE │ │ │ │WRITES │ │ │ │ │ ├──────┼──────┼──────────┼────────┼──────────┼──────────┼────────────────────┤ │16MB │2048 │/LAZY:on │40000 │30000 │20000 │512-1024 │ ├──────┼──────┼──────────┼────────┼──────────┼──────────┼────────────────────┤ │12MB │1536 │Same │Same │Same │Same │256-512 │ ├──────┼──────┼──────────┼────────┼──────────┼──────────┼────────────────────┤ │8MB │1024 │Same │Same │Same │Same │128-256 │ └──────┴──────┴──────────┴────────┴──────────┴──────────┴────────────────────┘ Case 4: HPFS and FAT with FAT Active ┌──────┬──────┬──────────┬────────┬──────────┬──────────┬──────────┬──────────┐ │RAM │CACHE │HPFS LAZY │MAXAGE │DISKIDLE │BUFFERIDLE│DISKCACHE │FAT LAZY │ │ │ │WRITES │ │ │ │ │WRITES │ ├──────┼──────┼──────────┼────────┼──────────┼──────────┼──────────┼──────────┤ │16MB │1024 │N/A │40000 │30000 │20000 │2048 │/LW │ ├──────┼──────┼──────────┼────────┼──────────┼──────────┼──────────┼──────────┤ │12MB │768 │Same │Same │Same │Same │1536 │Same │ ├──────┼──────┼──────────┼────────┼──────────┼──────────┼──────────┼──────────┤ │8MB │512 │Same │Same │Same │Same │1024 │Same │ └──────┴──────┴──────────┴────────┴──────────┴──────────┴──────────┴──────────┘ Based upon the file system and cache tuning testing, the following are true: o The HPFS actually requires 128 to 130K of committed memory -- as opposed to the widely perceived 512K. As cache size increases to 2MB (2048), this requirement increases as well, up to a maximum of about 240K. o The optimal cache size seems to be 1536. o When comparing the relative merits of the HPFS versus FAT, consider the following: On partitions of identical size, the HPFS gives you about 15% more space and performance is about 28% better! o Instead of continuing to increase performance, a DISKCACHE value in excess of 2048 seems to degrade performance rather than improve it. ═══ 11.5. 20 Questions About DCF/2 ═══ 1.) Can I compress HPFS partitions using the DCF/2? Yes, but you need to be running OS/2 2.11 (OS/2 2.1 plus the Service Pak) to do so. 2.) How does the DCF/2 differ from Stacker for OS/2 and DOS? o The DCF/2 allows the user to compress files stored on either FAT- or HPFS-formatted partitions. o The DCF/2 was designed for a multitasking operating system, OS/2 2.x -- not "ported" from a single tasking operating system, DOS. o DCF/2 compressed drives can "reside" on any device supported by OS/2 -- be they FAT- or HPFS-formatted, removable or network devices. o Compressed drives grow dynamically [--] the user doesn't have to pre-allocate a big chunk of space for the compressed drive. o DCF/2 is installed from OS/2 [--] not DOS. o All utilities are run from OS/2 [--] not DOS. 3.) What does "on-the-fly" mean? On-the-fly compression products like the DCF/2 create a special file, which serves as a container for compressed data. When an application request data stored in this way, the data is automatically compressed or decompressed "on-the-fly." The user does not issue a command to "unzip" or "unpak" the files he wants uncompressed. 4.) What is a VDU? VDU stands for Virtual Disk Unit. It is the term used to describe the architecture of the DCF/2's compressed drive. Like a physical disk unit, it works with low level OS/2 utilities like FORMAT and CHKDSK. Like a logical disk unit (e.g., a network drive), it isn't something you can reach out and touch. 5.) I haven't installed OS/2 yet. Which do I install first, OS/2 or the DCF/2? Install OS/2 first, then the DCF/2. 6.) I run dual boot. Can I access the compressed drive when I boot native DOS? Use the DCF/2 only to compress files and data you don't need access to when you boot native DOS. OS/2 must be running to access the compressed data. From DOS the VDU looks like a big file. The DCF/2 does give the user a great deal of flexibility with regard to picking and choosing what to compress and what not to compress. 7.) Do I have to back everything off of my system and reformat my hard drive? No. There is no need to back everything off of you drive or to reformat it before installing the DCF/2. 8.) Does the DCF/2 compress an entire drive automatically? No. Once a VDU is created and formatted, it is empty until the user moves programs and data onto it using the tools and utilities he normally uses to moves files and directories on his system, i.e., xcopy and delete or the OS/2 drives icon. The VDU grows dynamically as data is moved onto it. 9.) Can I compress OS/2? It is not recommended with version 1.2. You can compress WINOS2, EPM (the Enhanced Editor) and OS/2 reference files (.INF). However, if OS/2 needs to be reinstalled or the user plans to beta test a new version of the operating system, he or she should concentrate on moving program and data files to the VDU and leave OS/2 the full amount of space its installation requires. 10.) I am running OS/2 1.3. Can I use the DCF/2? No. The DCF/2 doesn't support OS/2 1.3. The DCF/2 requires OS/2 2.1 if your system is FAT formatted only, or OS/2 2.11 (OS/2 2.1 plus the service pak) if your system is either HPFS or a combination of FAT and HPFS. 11.) Can I compress floppies? Yes. 12.) Can I compress my magneto or read-write optical drive? Yes. 13.) Can I put VDUs on a network drive? Yes. 14.) Can I compress the OS/2 SWAPPER.DAT file? No, not with version 1.2. 15.) Does the DCF/2 "double" my drive? The compression ratio for a VDU will vary with the type and mix of data on the system. Typical compression ratios range from 1.5 to 1 (pre-compressed files, e.g., games, zipfiles, etc.) to 5 to 1 (user files, e.g., Ami Pro, etc.). Shipped with the DCF/2 is the Disk Compression Analysis Tool or DCAT. It is a simple utility program which allows the user to analyze the data on his or her system in terms of how much space could be recovered if it were stored on a compressed drive. 16.) Can I use the DCF/2 with OS/2 for Windows? Yes. 17.) Can I use the DCF/2 with the new OS/2 Performance Version? Yes. 18.) Does the DCF/2 support drive letter swapping so that after I compress everything on my D: drive, I still have only a D: drive? No. Drive letter swapping is not supported in version 1.2. The VDU takes the next available physical drive letter on the users system. For example, if the user's system has a C:, D: and E:, the first VDU will be drive letter F: and so on. 19.) Why are the VDUs always formatted using the HPFS? Because the HPFS is a much faster and efficient way to manage the data store on a computer system. In addition, it allows the user to use longer, more descriptive file names than the traditional "Eight-Dot-Three" naming convention. "Statements" to the effect that the HPFS requires half a megabyte of memory are completely wrong. Even with the maximum cache size allowed (2MB), the HPFS never uses more than about 230K of memory. 20.) I am using DOS 6 with compression. Does DCF/2 include a conversion utility? No. The user has to "unstack" the compressed drive, install OS/2 (if not already installed), then install the DCF/2 and move the data to be compressed onto the VDU(s). ═══ 11.6. Trademarks, Copyrights and Acknowledgements ═══ Proportional Software Corportation (PSC) provides this publication "as is" without warranty of any kind, either express or implied, including but not limited to the implied warranties of merchantability or fitness for a particular purpose. This publication could contain technical inaccuracies or typpographical errors. Changes are periodically made to the information herein and the changes will be incorporated in new editions of the publication. PSC may make improvements and/or changes in the products and/or the programs described in this publication at any time. o Trademarks and Copyrights o Acknowledgments ═══ 11.6.1. Trademarks and Copyrights ═══ DCF/2(tm) and Disk Compression Facility for OS/2(tm) are trademarks of Proportional Software. IBM(r) and OS/2(r) are registered trademarks and Presentation Manager(tm) is a trademark of International Business Machines Corporation. CompuServe(r) is a registered trademark of CompuServe Incorporated. Relish for OS/2 Presentation Manager(tm) is a trademark of Sundial Systems Corporation. Lotus (r), AmiPro for OS/2(r), 1-2-3 for OS/2(r), and Freelance Graphics(r) are registered trademarks of Lotus Development Corporation. FaxWorks(tm) is a trademark of SofNet, Inc. All other referenced products are trademarks or registered trademarks of their respective manufacturers. OS/2 files are being provided on behalf of IBM for maintenance purposes only and the rights and licenses to these files are governed by the terms and conditions of the user's OS/2 product license. Copyright June 1994, Proportional Software Corporation, 1717 Linden Lake Rd., Ft. Collins, CO 80524. ALL RIGHTS RESERVED. ═══ 11.6.2. Acknowledgments ═══ The DCF/2 has been a complex and challenging undertaking. Without the patience of our customers and the complete support of Lee Reiswig's OS/2 Team, the product would not exist today. Proportional Software gratefully thanks and acknowledges the contributions of the following individuals in particular: For invaluable technical assistance: The entire IBM OS/2 ISV Technical Support Group, and in particular -- Mr. Orlando Portella and Charles Buck II. In addition to the IBM OS/2 Technical Support Group, we express our appreciation to Mr. Colin Powell, Mr. Felix Miro, Mr. Sam Detweiler, Mr. James Taylor and Mr. Jack Boyce. For his technical assistance, Mr. Wayne Kovsky of COLORAD/OS2, and for their review of and comments on the documentation, Guy Scharf and Christy Scharf. For the wealth of information their books have provided: Mr. Mark Nelson, Mr. Raymond Westwater, Mr. Robert Lai, Dr. Mike Kogan : Dr. Harvey Dietel, Mr. Gilbert Held, Mr. Lawrence Kenah, Ms. Ruth Goldenberg, and Mr. Simon Bate. For their patience, moral support and encouragement: Ms. Robin Frank, Mr. Toby Pennycuff, Mr. Tim Heacox and Mr. David Jackson. For making it all worthwhile: our daugher Jennifer and son "Boo."